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/