RE: IPv6 Unicast Address Assignment Considerations

["John Spence" <jspence@native6.com>]

Guys - nice IETF Draft.  Lots of good considerations in there.  I'd like to
participate, so I've got some things to think about below.  Clarifications,
suggestions - hope they help move the discussion forward.  

Comments. 

*) In 1.0, you talk about Site-local and ULA.  Not sure if this should go
into the document, but during the transition this can be very tricky.  Most
implementations know about Site-local even though it is deprecated, and do
not know about ULAs - even though they are to spec.  I'm not sure, but my
guess is that may confuse the address selection algorithm in the transition
period.  Since your document is implementation-oriented, this might be worth
a mention.

*) Also in 1.0, you know that ARIN is considering portable address to
address the multihoming issue - right?  Not done yet, but I'll bet it goes
through.

http://www.arin.net/policy/proposals/2006_4.html

 
*) In 2.1, consider a sentence pointing out that scattering subnet /64
assignments, while still maintaining the ability to summarize routes, may
make active subnets harder to find, or guess, for an outsider, but that it
comes at the cost of complexity for the network operations team.

*) Also in 2.1, I'm not sure if it is the right place to mention it, but
today multihoming, with the aggregation model, pretty much means using
Policy Based Routing - do you agree?  If the source address will be chosen
based on the destination address, some mechanism must be used to make sure
the traffic egresses at the right interface through the right ISP.

*) In 2.2, you mention that a ULA is a /48 prefix.  You are correct per the
spec.  There was some traffic on the mailing list from before the RFC was
published where I suggested it be better to be more flexible on the length.
Suppose a site has a /47 because they are large enough to warrant it.  They
would probably like a /47 ULA to go with it, rather than using 2 /48s.  The
authors suggested that the spec was fine as is, but since these are internal
addresses enterprises could do what they wanted about using a shorter prefix
if that met their needs.  So, again, not sure it should go in, but it is
worth thinking about.

*) In 2.2 you have the word "chgoose" when you mean "choose".

*) In 2.4, you mention that multiple /48s in a single enterprise will be
non-contiguous, and that is not good for summarization.  I agree, but do you
think that would be a problem in practice, since a whole /48 is still a
large summary route.  If you had a really big enterprise (say /40), if you
have /48 summarization that is only 256 routes in the internal-enterprise
backbone routers.  Seems pretty good.  Now if you had a lot of /62s, or
/60s, that would be a problem. But I don't know if having to announce, say,
8 /48s when you might have been able to announce a single /45 would make a
big difference, in practice.

*) Man, it is hard to keep up.  You reference RFC 3513 - 4219 is out now.

ftp://ftp.rfc-editor.org/in-notes/rfc4291.txt  

*) In 3.3.1, the Subnet Anycast Address is where all the non-prefix bits are
all zeros:

ftp://ftp.rfc-editor.org/in-notes/rfc3513.txt (2.6.1)

http://www.iana.org/assignments/ipv6-anycast-addresses

*) In 4.2, for "reverse DNS lookup", I suggest making it more clear that
using privacy extensions for a host that needs to be in the DNS, if not
using DDNS, is not recommended, as is practically impossible to maintain.  I
think some people might not get that from what you have.

*) In 5.1, can you include an estimate of the number of subnets too?

*) In 5.1.1, do not some people use site-local or ULA address for the
infrastructure not because they are lacking addresses, but for security
reasons, figuring that there need be no outside-the-enterprise
communications with the control-plane, and so using ULAs improves security?
If so, you might note that here as a practical consideration.

*) In 5.1.2, does the allocation of a /56 to each school result in,
essentially, smooth aggregation for the network?  Or do you leave that
behind, figuring that /56s are large enough summaries by themselves, because
the convenience of having each school on a /56 yields other benefits (than
full summarization)?

*) In 5.1.4, do you really let hosts autoconfigure, then put their address
manually in the DNS?  Why not give them a simpler, manual address that would
survive NIC swap-outs?


-----Original Message-----
From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf
Of Gunter Van de Velde (gvandeve)
Sent: Sunday, March 05, 2006 12:58 AM
To: v6ops@ops.ietf.org
Cc: tjc@ecs.soton.ac.uk; cpopovic@cisco.com
Subject: Fwd: IPv6 Unicast Address Assignment Considerations

Resend of original message as i apparently did not reach the overall v6ops 
alias.

G/

>Date: Tue, 21 Feb 2006 13:34:00 +0100
>To: v6ops@ietf.org
>From: "Gunter Van de Velde (gvandeve)" <gvandeve@cisco.com>
>Subject: IPv6 Unicast Address Assignment Considerations
>Cc: tjc@ecs.soton.ac.uk, cpopovic@cisco.com
>
>Dear all,
>
>The authors of the following draft would be interested in comments
>on the draft <IPv6 Unicast Address Assignment Considerations>
>
>http://www.ietf.org/internet-drafts/draft-vandevelde-v6ops-addcon-00.txt
>
>Kind Regards,
>G/