Subject: mboned: I-D ACTION:draft-ietf-mboned-addrdisc-problems-00.txt

From: [email-masked]
Date: Wed, 23 Mar 2005 16:12:28 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the MBONE Deployment Working Group of the IETF.

	Title		: Lightweight Multicast Address Discovery Problem Space
	Author(s)	: P. Savola
	Filename	: draft-ietf-mboned-addrdisc-problems-00.txt
	Pages		: 10
	Date		: 2005-3-23
	
Typically applications developers have requested static IANA
   assignments for the applications, even if the applications would
   typically be only used within a site, between consenting sites, or
   would not eventually even use multicast at all.  This memo describes
   this problem space, and summarizes a number of proposed approaches to
   mitigating these problems.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mboned-addrdisc-problems-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-mboned-addrdisc-problems-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-mboned-addrdisc-problems-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Beau Williamson <[email-masked]>
Date: Thu, 24 Mar 2005 12:36:49 -0600

Pekka,

I'd like to see the following text marked with ">>" (or something like it) 
added to the end of the following section at some point in the near future.

3.1  Locally Scoped Address Assignment by IANA

If we ignore the first problem about local scoping, the easiest mitigation 
technique might be having IANA assign locally scoped addresses on FCFS 
basis (like UDP/TCP port numbers).  This could be done inside or outside of 
239/8.

...

 >>Having IANA suddenly begin assigning addresses in the 239/8 space has 
the potential for causing serious impact to existing organizations that 
have deployed multicast as this address space has, up to now, been 
considered "private" multicast address much like RFC 1918 address space for 
unicast.  Existing organizations have made use of the 239/8 address space 
for various private scope ranges under the assumption that this space is 
"private" and would never be assigned. These organizations would have to 
completely re-engineer their private network's internal scoping and scope 
address range plans should IANA begin to assign addresses in the 239/8 
space. The impact of this should be CAREFULLY considered and ALL OTHER 
methods explored before adopting this approach.

Beau

At 3/23/2005 03:12 PM, [email-masked] wrote:
>-------------------------------------------------------------------------
>CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY
>-------------------------------------------------------------------------
>In order to maintain computing infrastructure integrity, Cisco Systems
>Enterprise Messaging Services and InfoSec teams have set a mail policy
>disallowing executable attachments in email.
>
>This message contained an executable attachment type that is prohibited
>by this policy. The attachment has been removed from this message and
>copied to quarantine by our systems. It will be held in quarantine for
>seven days in the event that the content needs to be retrieved.
>
>Please be aware many viruses attempt to look like legitimate email or
>notifications from anti-virus systems. We will clearly mark a seperation
>between our notifications and the original email as follows:
>
>   "CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY"
>
>For further reference information about viruses and email antivirus
>efforts within Cisco, please visit:
>
>http://wwwin.cisco.com/it/ems/services/antiviral
>
>If your concern isn't addressed by the information in this notification
>or the above web page, you may open a support request:
>
>http://wwwin.cisco.com/support/
>
>Select "Messaging", "Email-Related", "Mail Routing"
>
>Please include in the text of your case the following information:
>
>* Full headers of the message. Documentation on displaying the full
>headers is available at this URL:
>
>http://wwwin.cisco.com/support/library/faqs/solution002471.html
>
>* This unique quarantine identifier: j2O3J4J2021491
>
>If the matter is urgent, you may follow up by calling one of the below
>referenced numbers. Please make every effort to provide the above
>requested information via the support web tool prior to calling as it
>will greatly aid the resolution of your issue.
>
>Americas:
>1 408 526 8888
>
>Asiapac
>+61 2 8446 8888
>
>EMEA
>+31 20 485 4888
>
>Japan
>+81 3 5549 6888
>
>US (Toll Free)
>1| 800| 888| 8187| (ext.68888)
>
>Thank you for your cooperation,
>
>Enterprise Messaging Services
>Cisco Systems, Inc
>Content-Type: Multipart/Alternative; Boundary="OtherAccess"
>
>
>--OtherAccess--

---

From: Pekka Savola <[email-masked]>
Date: Fri, 25 Mar 2005 08:39:57 +0200 (EET)

> added to the end of the following section at some point in the near future.

I agree with the main thrust of what you're saying, and I'm OK with 
adding some text like that.

John (K.) however thought it might still be a good idea.  Would you 
(John, others) be OK with the text proposal (below)?  Any 
wordsmithing?

> technique might be having IANA assign locally scoped addresses on FCFS basis 
> (like UDP/TCP port numbers).  This could be done inside or outside of 239/8.
>
> ...
>
>>> Having IANA suddenly begin assigning addresses in the 239/8 space has the 
> potential for causing serious impact to existing organizations that have 
> deployed multicast as this address space has, up to now, been considered 
> "private" multicast address much like RFC 1918 address space for unicast. 
> Existing organizations have made use of the 239/8 address space for various 
> private scope ranges under the assumption that this space is "private" and 
> would never be assigned. These organizations would have to completely 
> re-engineer their private network's internal scoping and scope address range 
> plans should IANA begin to assign addresses in the 239/8 space. The impact of 
> this should be CAREFULLY considered and ALL OTHER methods explored before 
> adopting this approach.
>
> Beau
>

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/

---

From: John Kristoff <[email-masked]>
Date: Mon, 28 Mar 2005 17:18:03 -0600

On Fri, 25 Mar 2005 08:39:57 +0200 (EET)

> (John, others) be OK with the text proposal (below)?  Any 

After the initial discussion I'm convinced that it isn't such a
great idea.  It was the simplest option I thought of so it is worth
documenting as you've done with this and others.  Thanks for taking
the time to do this.  I'll add my thoughts to the specific wording
below.

> > (like UDP/TCP port numbers).  This could be done inside or outside of 239/8.

I don't share Beau and Albert's concerns about using a block in 239/8,
but I also don't share their experience so they are probably on to
something.  I would like to say that I feel very little sympathy for
anyone or organization who considered 239/8 to be like RFC 1918 space.
It seems to me those folks failed to properly implement RFC 2365 (and
that includes my current organization :-).

Perhaps combining your original wording and based partly on Beau's
comments against 239/8 as well as other argument against static
assignments, how about something like this:

     If we ignore requirements for different levels of scoping, the
     simplest approach would be to make globally unique assignments
     within a well known local scoped address block.  Group address
     assignments could be made by IANA to applications on a first
     come first serve basis, much like what is done for port numbers
     used in protocols such as SCTP, TCP and UDP.  This well defined
     range could then be scoped at the public Internet boundaries to
     ensure private usage remains private.

     Theoretically, reserved space within the administratively scoped
     address range (239/8) defined by RFC 2365 that could be used
     for such a purpose.  This address range should even be scoped at
     public Internet boundaries already.  However, many organizations
     are already making use of the entire administratively scoped range.
     For better or worse, we feel that it is now too late to reclaim
     the reserved address space within the administratively scoped
     range for the problem case described here even if it were to be
     appropriate to do so.

     If we consider multiple levels of scoping, using static address
     assignments may be problematic for sites with the need to separate
     applications between their local boundaries.  If no other scoping
     mechanism is used, the network would have to create and maintain
     complex forwarding and filtering rules to ensure group membership
     for the well defined group address does not leak outside the
     desired local scope.

     Even if a well defined local scope address range could be used
     and additional levels of scoping were not an issue, it is not
     clear that multicast application developers would accept a local
     scoped address over a globally routable one.  Given the choice
     of a local scoped assignment and a global one, what incentive is
     there for an application developer to choose a local scoped one
     if there is even a faint chance of global usage?

     An additional, fundamental question with static address assiginment
     in the multicast address space (224/4) is, how big of an address
     range should be reserved?  Existing multicast applications in use
     have been written to use an address block as large as a /8.  Any
     allocation on this order is clearly diminishing the limited pool
     of already limited IPv4 multicast addresses.

John