On Mon, 26 Jan 2004, Brian Haberman wrote:
> This is the start of an IPv6 working group last call on:
>
> > Title : Unique Local IPv6 Unicast Addresses
> > Author(s) : R. Hinden, B. Haberman
> > Filename : draft-ietf-ipv6-unique-local-addr-02.txt
> > Pages : 16
> > Date : 2004-1-21
Below are my comments. I don't think we really need this kind of
stuff, but as local addressing seems to have been taken as granted
already, I don't argue on those grounds. (However, at some point I
believe someone will make you insert a better applicability statement
on where to (not) use the local addressing.. you could very well try
to do it now.)
As for the rest, I have a major concern on picking just one registrar
for the central allocations. I also have major deployment and
implementation concerns with "default deny" policies; they seem to be
unacceptable or unfeasible. The security of local addressing must be
based on the fact that the site administrator has toggled on a switch
or configured the access-lists -- NOT on protocols having to filter
out the addresses, or having some kind of default access-lists
magically deny all the traffic at vague site borders.
Below..
substantial
-----------
1) specifying just one allocator to the end-sites; this is always bad
and prone to create monsters such as ICANN.
It seems like that the model should be provided to support
enough registries (e.g. 2 bit = 4 or 3 bits = 8). Just to make sure that
the customers can pick someone else's service unless they aren't satisfied
with an organization, so that there is some incentive not to have too high
charges, to avoid the claims of building monopolies who get free money for
numbers, etc.etc.
Unless you have instructions in mind for IANA who should have this registry
monopoly, there should probably be multiple registries in the only one of
them screws up in a major way (e.g., compare to the mess with .com zone by
verisign).
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.
If BGP is being used at the site border with an ISP, filters MUST be
installed by default in the BGP configuration to keep any Local IPv6
address prefixes from being advertised outside of the site or for
these prefixes to be learned from another site. The exception to
this is if there are specific /48 routes created for one or more
Local IPv6 prefixes.
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.
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.
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 :-)
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.
Site border routers SHOULD install a black hole route for the Local
IPv6 prefix FC00::/7.
==> I think you mean "a reject route" ? (or a "discard" route might
also work OK)
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.
Local IPv6 addresses, like global scope unicast addresses, are only
assigned to nodes if their use has been enabled (via IPv6 address
autoconfiguration [ADDAUTO], DHCPv6 [DHCP6], or manually) and
configured in the DNS.
==> "and configured in the DNS" is not requirement and is irrelevant; should
be removed?
assign them. In order for a node to learn the Local IPv6 address of
another node, the Local IPv6 address must have been installed in the
DNS.
==> s/DNS/DNS or another naming system/ ?
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.
editorial
---------
==> please include the IPR and copyright sections if possible..
INTERNET-DRAFT R. Hinden, Nokia
January 20, 2004 Brian Haberman, Caspian
==> s/Brian/B./ (same style :)
This document defines an unicast address format that is globally
==> s/an/an IPv6/
interface ID 64-bit IID as defined in [ADDARCH].
==> s/IID/interface ID/
prefix and Global ID field length. There is a direct tradeoff
==> s/Global ID/global ID/ -- or at least be consistent whether it starts
with the upper case in the middle of sentence or not (the same with a few
other places)
needlessly. A reasonable way of evaluating a specific field length
is to compare it to a projected 2050 world population of 9.3 billion
[POPUL] to compare the number of resulting /48 prefixes per person.
==> s/to compare/and/ (the latter "to compare")
Prefix Global ID Number /48 Prefixes % of IPv6
Length Prefixes per Person Address Space
==> s/Number/Number of/
==> IPv6 Address Space goes beyond 72 words/line, which is bad.
A very high utilization ratio of these allocations can be assumed
because no internal structure is required in the field nor is there
any reason to be able to aggregate the prefixes.
==> sounds soooo awkward, maybe reword:
A very high utilization ratio of these allocations can be assumed
because the global ID field does not require internal structure,
and there is no reason to be able to aggregate the prefixes.
...
The authors believes that a /7 prefix resulting in a 41 bit Global ID
==> s/believes/believe/
exhausted. If more than this was needed, then additional IPv6
address space could be allocated for this purpose.
==> s/was/were to be/ ?
should not be assigned sequentially or with well known numbers. This
to ensure that there is not any relationship between allocations and
==> s/This/This is/
duplicate assignments. The local assignments are free and do not
need any central coordination or assignment, but have a lower (but
==> remove "are free and" due to removing the 10 euro charge text?
(without coordination or assignment, there certainly can't be any
fee to them :)
This is easiest to accomplish if there is a single source of the
assignments.
==> sounds funny, maybe s/of/for/ ?
addition to web based registration they should support some methods
like telephone, postal mail, fax, telex, etc. They should also
==> perhaps it has been long enough to be able to remove "telex" from the
list :-)
It is escrowed to insure there are no duplicate allocations and in
==> s/insure/ensure/ (the same elsewhere)
makes it easy to get a prefix with out the need to contact an
==> s/with out/without/
is adequate for sites planning a small to moderate amount inter-site
communication using locally generated global IDs. Sites planning
==> s/amount/amount of/
[ICMPV6] Conta, A., S. Deering, "Internet Control Message Protocol
(ICMPv6) for the Internet Protocol Version 6 (IPv6)
Specification", RFC1885, December 1998.
==> old reference.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", RFC 2026, BCP00009, October 1996.
==> remove this, unused reference.
[RTP] Schulzrinne, H., S. Casner, R. Frederick, V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications"
RFC1889, January 1996.
==> use RFC3550 instead.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
