At 12:13 PM 2/3/2004, Pekka Savola wrote:
Inline..
likewise...
On Tue, 3 Feb 2004, Bob Hinden wrote: > The text in the IANA considerations section calls for the IANA to set up a > "allocation authority" for the centrally assigned ULA prefixes. The exact > details of how to do this (i.e., one or many organizations doing the > assignments, who it is, etc., etc.) are left to the IANA as long as they > meet the requirements stated in the document.
I read "an allocation authority" as singular, just one organization. As the space is specified to be non-hierarchical and the randomizer algorithm is specified to use LSB 40 bits for centrally allocated prefixes, this does strongly imply a single organization (or organizations with a pretty well-synched up database :).
That was certainly the original intent, but at the same time I don't think the current text limits it to a single organization as long as the allocations are made in a manner as if a single organization was doing it. For example, if the IANA ran the algorithm a million times and then assigned a hundred thousand of the prefixes to ten organizations (and then repeated as required) that would be consistent with text and satisfy your concern about a single organization.
Note, I don't have the same issue you have with a single organization, so opinions vary on this. I think the current text is a reasonable middle ground.
> I am comfortable with the IANA doing this in a manner that will be > beneficial from the community. It is also, of course, out of scope > for the IETF to specify more than the allocation requirements, which > this document does do. We have learned from past experience it's not > wise to over specify when asking the IANA to do address allocation. > I think the current text is about right in this regard.
If folks think this is OK, it's fine by me. Clarification in IANA considerations like "If deemed appropriate, the authority may also consist of multiple organizations performing the authority duties" might be in order though.
I will take a look at the IANA considerations text and see what can be done.
> >2) The specification requires that routing protocols special-case these > >prefixes by MUST filtering them. This is unacceptable, and should be > >removed. Any filtering should be done by the sites themselves. Note that > >running any other protocol than BGP is not feasible anyway to be run over > >administrative domains (exclusing provider-provisioned VPNs, maybe, but > >those are special case anyway), so we can pretty much limit the discussion > >to BGP. Which is pretty trivial, because 1) why would the ISP advertise > >such prefixes, and 2) why would the site not filter out stuff it doesn't > >want. > > > > Any routing protocol that is used between sites MUST filter out any > > incoming or outgoing Local IPv6 unicast routes. The exception to > > this is if specific /48 IPv6 local unicast routes have been > > configured to allow for inter-site communication. > > I agree this could be stated better. I think it would be good to > change it to "Any router that is used between sites....", as it is > not the routing protocols doing the filtering, but the router based > on it's configuration.
But then it's an operational guidance, right? Maybe not uppercase material?
I don't have any problem making this change, but I don't understand the difference between upper and lower case in these sections.
> The requirement is that the FC00::/7 is > filtered by default by routers at the site boundary. As Brian > Carpenter pointed out if there is a filter for this prefix > configured by default in all routers, it does no harm as sites that > wish to use these addresses would add more specific routes that > would override the default filters for these more specific prefixes.
Please check my response to Brian. There is a very specific difference of "FC00::/7 reject route" and "FC00::/7" filter. If you mean the former -- fine, it works in most cases (except the stub router and no IGP case I mentioned) -- if the latter, you're in for a lot of trouble. Something like this would be very difficult to implement properly.
The intent was "reject route". I will clarify the text.
> >3) Similar to the above, there are some particularly inpractical issues with
> >site-border security:
> >
> > Site border routers SHOULD install a black hole route for the Local
> > IPv6 prefix FC00::/7. This will insure that packets with Local IPv6
> > destination addresses will not be forwarded outside of the site via a
> > default route. Site border routers SHOULD respond with the
> > appropriate ICMPv6 Destination Unreachable message to inform the
> > source that the packet was not forwarded [ICMPV6]. This feedback is
> > important to avoid transport protocol timeouts.
> >
> > Site border routers and firewalls SHOULD NOT forward any packets with
> > Local IPv6 source or destination addresses outside of the site unless
> > they have been explicitly configured with routing information about
> > other Local IPv6 prefixes. The default behavior of these devices
> > SHOULD be to filter them. Site border routers SHOULD respond with
> > the appropriate ICMPv6 Destination Unreachable message to inform the
> > source that the packet was not forwarded.
> >
> >.. this is inpractical, and should be reworded. The site border routers
> >cannot know that they are site-border routers, so these checks cannot be
> >implemented. What you can do is state that a toggle SHOULD be implemented
> >and when enabled on an interface, it would apply these kind of restrictions
> >to it. But the point is that you WILL need administrator action. "Deny by
> >default" just is not practical approach here, because you don't know that
> >you should be denying these by default.
>
> I don't agree. As stated above if the /7 prefix is filtered by default, it
> does no harm. But I think changing the text to make it clearer that these
> routers should be configured to do this filtering would make the text clearer.
"Filtered" has entirely different implications whether it's "done" (inpartially) with a reject route, or done with access lists. See my note to Brian. "access-lists by default" pretty much by definition WILL block the more specifics, and are difficult to deploy or specify here.
I will clarify that it should be a "reject route". That also consistent with providing the ICMP feedback.
> > Additionally, domain border routers connecting autonomous systems
> > throughout the Internet SHOULD obey these recommendations for site
> > border routers.
> >
> >==> as for this, I have no idea what this even tries to say, so it requires
> >rewording.
>
> It is trying to say that routers that connect autonomous systems also be
> configured to do this filtering. Even if they are not at site
> boundaries. How about:
>
> Routers that maintain peering arrangements between Autonomous
> Systems throughout the Internet SHOULD obey the recommendations for
> site border routers unless configured otherwise.
Ok, that's understandable. But again, why use an uppercase SHOULD keyword? This is a requirement for operators, not a protocol interoperability issue?
As above, please explain the difference?
> >semi-editorial > >-------------- > > > > 2) Obtain an EUI-64 identifier from the system running this > > algorithm. If an EUI-64 does not exist, one can be created from > > a 48-bit MAC address as specified in [ADDARCH]. If an EUI-64 > > cannot be obtained or created, a suitably unique identifier, > > local to the node, should be used (e.g. system serial number). > > > >==> hopefully the centrally assigned global IDs don't use their > >(single) computer's EUI-64 in the generation :-) > > I don't think this is a problem. Every time the algorithm is run the time > would change resulting in a new distinct allocation. The MD5 hash > guarantees it.
Sure, but the amount of entropy given as input to the has function is significantly lower. For central allocations this is probably not a problem.
Agreed.
> > 4) Compute an MD5 digest on the key as specified in [MD5DIG]. > > >==> security folks have been pushed for the use of SHA-1 because it's more > >collision-proof. It doesn't matter much in this specific context, but at > >least nobody would object if you changed this to using an SHA-1 digest. > > As you said, "it doesn't matter...".
If you feel so. This might come up at IESG review from security ADs though :).
I am sure they will have something to say whatever is in the document :-)
> > For future study names with Local IPv6 addresses may be resolved > > inside of the site using dynamic naming systems such as Multicast > > DNS. > > > >==> this seems irrelevant and should be removed; above, it already > >states someting general about local naming systems. > > I don't see it doing any harm either.
This is an unnecessary plug for Multicast DNS.
(btw, if it stays, it should be reworded for better english..)
OK.
> >11.2 Disadvantages
> >
> >==> Add to disadvantages:
> >
> > - Instead of using global unicast addresses inside the sites, the
> > sites may be tempted to start using Local IPv6 addresses excessively,
> > instead of using global unicast addresses and reachability restrictions
> > such as firewalls or access control lists
>
> I think this is out of scope for this document.
Applicability statements or reality checks are in scope for all kinds of documents. :)
But as can be seen from the volume of mail on the merits of appropriate use of local vs. global addresses, opinions do vary widely on this. I don't think it would be very productive to repeat that discussion.
I don't think this document has any chance of passing through the other reviews unless it spells out its usability (and especially nonusability!) better.
I'm not sure that adding a rather architectural disadvantage is enough but it could be a start.
I agree that as this document progresses through the process other changes will likely be required. Has any document ever gone from a w.g. through the IESG without any changes :-)
Thanks, Bob
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
