RE: draft-ietf-ipv6-ula-central-02.txt

["Tony Hain" <[e-mail]>]

I have a few points on Paul's draft:

Nit - LocalNum = 28 bits (you lost 4 bits somewhere)

Minor point - 5.1 is not globally true yet, but should be

Major complaint -  aggregation
	There needs to be at least a modest capability to aggregate. I
understand the aversion to having these show up in the DFZ, but if 5.1 were
really true that would not be an issue. The use case that needs to be
supported is for internal aggregation of private peering clusters. Global
organizations have many external relationships, but typically have them
clustered in small groupings for logistics reasons. At the same time they
don't necessarily want to carry the explicit routes for every organization
throughout their internal network. If the ULA-C/G space has some modest
aggregation  like sparse allocation of the RIR num block to allow clustering
subsequent block to the same RIR and a suggestion for E-W-N-S regional
management within the RIR space, then it would be possible to aggregate the
internal routes to these private peering clusters. 


5.6 last sentence seems to be prescriptive, and would be more descriptive if
opened with 'It is expected that ...'

6.1 - One point of the entire ULA space is that this is a different
'filtering process'. Where typical filters block packets received at the
border for the target address, the ULA space is about not even having a
route for that packet in the first place. Yes there is no more or less
security than any other unicast address when routing announcements and
packet filtering match, but the default assumption that ULA is a bogon
routing announcement should add a layer of security that can't be done with
PI for most use cases.

Tony 


> -----Original Message-----
> From: Paul Vixie [mailto:[e-mail]]
> Sent: Wednesday, July 11, 2007 7:24 AM
> To: [e-mail]
> Subject: Re: draft-ietf-ipv6-ula-central-02.txt
> 
> > Paul's draft which assigns 12 bits to each RIR seems to be the right
> > thing since it clearly delineates which RIR is responsible for each
> > subset range, and therefore if an RIR policy dictates special
> handling
> > for certain ULA addresses, there is a simple technical means to
> > accomplish this.
> 
> it's expected that iana will hand out blocks of 100 RIR-sized ULA-G
> blocks
> to each RIR, similar to how ASN blocks are assigned, just to save
> paperwork.
> but yes, since each RIR will have its own chunks of this space, they
> can do
> whatever their regional member-driven policy development process tells
> them
> to do as far as carving it up and handing it out to LIRs, endusers,
> etc.
> 
> > I'm not sure what the status of Paul's document is since the drafts
> > directory only contains this one:
> > http://www.ietf.org/internet-drafts/draft-ietf-ipv6-ula-central-
> 02.txt
> >
> > Is Paul's superceding that or is there a merge in process?
> 
> the other authors of ula-global have not commented on my hijackery.
> they
> might be supportive, or angry, or complacent, about the draft-fork i
> made.
> maybe they'll want their names removed.  maybe they'll want to merge
> ula-g
> into ula-c and have my name removed.  maybe they'll want the fork to
> stay.
> 
> the i-d editor determined that my submission came after the chicago
> cutoff,
> which really oughtn't apply for WG's that are not meeting, but so it
> goes.
> 
> the WG chairs have ignored my mail thus far.
> 
> so my take is, suggested changes and statements of opposition||support
> can
> be made based on the text at http://sa.vix.com/~vixie/ula-global.txt.
> i'll
> be rev'ing the draft based on james' and scott's comments shortly.
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------


--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------