Subject: mboned: draft-ietf-mboned-ipv4-uni-based-mcast-01.txt

From: David Meyer <[email-masked]>
Date: Tue, 20 Jan 2004 09:40:02 -0800

Folks,

	My mistake. I thought this one was on the I-D
	repository. I'm cancelling the LC and I'll reissue it
	when it gets there (if there isn't significant negative
	feedback before then). 

	Dave
_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 20 Jan 2004 12:23:46 -0800

On Tue, Jan 20, 2004 at 09:40:02AM -0800, David Meyer wrote:
> 	when it gets there

No problem. I thought it was the authors responsibility to  make sure
a draft he wants going forward is available.

>       (if there isn't significant negative feedback before then). 

Oh, that's my prompt: 

  I think the draft shows a very logical and well written technical
  possibility, and i don't want to argue the technical merits, but
  rather the operational implications:

  Unlike the current IANA address allocation or hopefully a future
  extended GLOB address assignment via some registry, this mechanism
  does not create any documentation as to what application or
  purpose is associated with a particular group address. I do
  very much like to have this for addresses intended to be used on
  a permanent/well-known basis in the global scope.

  If instead we are talking about non-global scope or non-permanent
  assignments, then of course documentation isn't all that important,
  but this draft does not help there. It does not cover non global
  scope addresses, and i think it does not provide much value for
  non-permanent assignment: If you just want to broadcast across the
  internet in ASM some TV channels for some period of time, the current
  FCFS assignment in 224.2/16 has proven to be quite sufficient: conflict
  resolution is not a problem, the only problem is DoS, and that's an
  ASM problem not an address-range problem and the new method does not
  change it.

  But even if we agree on some value of this method for temporary usage,
  it is far outweighted in my opinion by the problem that it will
  be used in an uncontrolled way to allocate addresses on an effectively
  much more permanent basis by users:

  Example:

    - A small application developer writes a multicast application, wants
      to have a well-known multicast address for it, and simply takes the
      one address that he gets through the class-C network of his company.
      He puts out his application and it actually spreads across the
      internet (dream mode on: It might be a file-sharing application
      using multicast ;-). Now this developer changes the ISP, or goes
      out of business, or simply a year passes and the IETF reconsiders
      the assignment for the /8 to this mechanism, and voila, you've got
      trouble because now you've got an address assigned and in use where
      you either don't know anymore who owned it (imagine the new company
      getting the class-C network and seeing that their only group-address
      for this mechanism is widely spread by the prior owner.

   I think that all address assignment we see will finally fall into this
   category. So effectively we can forget about trying to establish
   this method as a temporary solution, it will by effect of users simply
   applying it in the above described way become a FCFS undocumented
   permanent assignment of global scope multicast addresses - and why
   would i want to have that ?

   So, here's what i think we could do:

   a) Don't do this at all, but instead pursue eGLOB.

   b) Change this draft to define a controlled allocation of global
      scope multicast addresses by IANA or some delegated allocation
      authority.

      Here's how:

       - If user comes to request global scope IP multicast address
	 from this space, he has to:

	 1. Provide documentation what this is used for and how long
	    it is inteded to be kept.

	 2. Declare which IP unicast prefix he owns and against which
	    his address request is to be accountet.

	 3. Authenticate himself by using credentials for that
	    unicast prefi (eg: verified email addresses or the like
	 
	 There is NO NEED to provide justification for the allocation
	 (as there is now if you simply want to get multicast addresses
	  from IANA). Instead the policy is: If you control N IP unicast
	  addresses, you can get up to N/256 multicast addresses.
	 
       - The address assignment agent will then hand out an amount of
	 IP multicast addreses not exceeding 1/256th of the IP unicast
	 address space in total for this requester.
      
      This method has a lot of advantages:

      1. It creates documentation and a traceable pointer back to
	 a responsible contact for the address, but it does not
	 require justification.

      2. The whole process can be fully automated via a web-page
	 (with access to unicast prefix registry information and for example
	  using some automated email exchange to validate identity).
      
      3. Given that it can be fully automated, it can create a web-accessible
	 list of allocated addresses.
	 
	 This would make it possible for operators to download
	 periodically an updated list of assignments automatically and 
	 put it into filter lists at key locations (eg: MIXes).
	 
	 Thus we can get an automatic filtering to only allow documented
	 and allocated global scope addresses. Which is very valuable
	 because now operators know always a responsible owner to contact
	 for multicast traffic flowing through their network.
       
       4. Address assignments can be automatically invalidated if they
	  expire, or when the owner information of the unicast prefix used
	  as credentials changes.
       
       5. Depending on what we define as the policy it is not necessary
	  to actually invalidate assignments when the owner changes
	  the service providers because the assignment does not have
	  to be necesarily the fixed algorithmic mapping.
	  
	  Instead this algorithmic mapping can be just the default
	  algorithm applied by the allocation authority, but effectively
	  it can use _any_ fre multicast prefix delegated to it by IANA
	  for this type of allocation.

	  Example:
	  
	  User owns 192.44.81/24, goes to web page to request 
	  a global scope multicast address. Fills in web-page stating
	  purpose and contact information, validates with email address
	  and may also have some other fields - like for example a
	  password for this allocation (allocation server will just store
	  MD5 of this).

	  Web-server sends email with password to email-address listed
	  in registry for 192.44.81. When reply with this password is
	  received by allocaiton server, it will hand out one ip multicast
	  address. This could by default be 237.192.44.81, or it could
	  be any other address (eg: when that one address was already
	  taken by a previous owner).

	  When the user later on changes service provider, he may loose
	  192.44.81/24, but he wants to maintain his assigned address.
	  So he revalidates with the allocation server by using his
	  password, which the allocation server validates against the
	  MD5 stored with this allocation). Now the user has just to
	  provide new unicast prefixes owned by him to be used as
	  effectively the "payment" to keep this allocation.
	  ... still all automated.

      And by the way: I would not have a problem if one global
      scope IP multicast address assigned via such a method would for
      example cost $10..$50 per year. With this amount of money it should
      be easy to find some registry willing to operate the automated
      allocation server.

Cheers
	Toerless