[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: IPv6 Unicast Address Assignment Considerations

Hi John,

Thanks for the review and reading the text. See inline


At 18:12 7/03/2006 -0800, John Spence wrote:


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.


ok, will make a note of that in the text.



*) 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



Is there an indication when they will happen? I think the draft should follow
as its implementation oriented, but not lead as long as the ARIN decision is not fallen. 



*) 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.


ok, will do. It fits inline with the IPv6 NAP concept



*) 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.
If what one wants to achieve is that when sending packets that just those packets from a certain IPv6 source-address-range gets routed to/over the ISP responsible 
for that range. That is not always true as the network administrator may
have a different policy of load-balancing. One item to keep in mind is the
impact on RPF checks. IPv6 RPF check may very well break connectivity
in IPv6 due to the aggregation principles. I'm not sure if this has been researched yet. 


*) 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.


i think as 'per spec' must be in the document. The /47 can be good to add
as background context, but i'm not sure that is within the scope we intended.
Maybe there are other opinions from people in the v6ops alias or from the co-authors? 


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


oeps... thanks :-)


*) 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.


Thanks, i believe we can make a note of your observation in the text


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

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


tx. will adjust


*) 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.


ok, we can rewrite.

I will leave the other sections for Tim as he edited the study.


*) 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?



Many thanks again for your detailed review comments and observations,
Groetjes,
G/



-----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/