Subject: Fwd: IPv6 Unicast Address Assignment Considerations

From: "Gunter Van de Velde (gvandeve)" <[email-masked]>
Date: Sun, 05 Mar 2006 09:58:18 +0100

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: [email-masked]
>From: "Gunter Van de Velde (gvandeve)" <[email-masked]>
>Subject: IPv6 Unicast Address Assignment Considerations
>Cc: [email-masked], [email-masked]
>
>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/

---

From: "John Spence" <[email-masked]>
Date: Tue, 7 Mar 2006 18:12:40 -0800

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: [email-masked] [mailto:[email-masked]] On Behalf
Of Gunter Van de Velde (gvandeve)
Sent: Sunday, March 05, 2006 12:58 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Fwd: IPv6 Unicast Address Assignment Considerations

G/

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 7 Mar 2006 21:39:03 -0500

Hello;

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

There is also

http://www.arin.net/policy/proposals/2005_1.html ,

which is a competing proposal.

I am confident that something along these lines will eventually go  
through. 2002-3 took quite
a while too.

Regards
Marshall Eubanks

---

From: Stig Venaas <[email-masked]>
Date: Thu, 16 Mar 2006 09:34:43 +0100

Some comments on 3.3.2.  Addresses used by Embedded-RP (RFC3956)

    Embedded-RP [18] reflects the concept of integrating the Rendezvous
    Point (RP) IPv6 address into the IPv6 multicast group address.  Due
    to this embedding and the fact that the length of the IPv6 address
    AND the IPv6 multicast address are 128 bits, it is not possible to
    have the complete IPv6 address of the multicast RP embedded as such.

    This limitation resulted in a restriction of 15 possible multicast
    addresses per subnet prefix.  The space assigned for the embedded-RP

The number of multicast addresses per prefix is huge, what you want to 
say, is that there are 15 possible RP addresses per prefix that can be 
used with embedded-RP. For each of those you have 32 bits for multicast 
addresses.

    is based on the 4 low order bits, while the remainder of the
    Interface ID is set to all '0'.

                [IPv6-prefix (64 bits)][60 bits all '0'][RIID]

                    Where: [RIID] = 4 bit.

    This leads to the constraint that when creating subnet lengths longer
    than 64 bits, the bits between bit 65 and the subnet boundary should
    not be set to be all "0".

I don't understand this constraint. If all 64 low order bits (apart from 
the lowest 4) are 0 it's possible to use embedded-RP even for prefixes 
longer than /64. This is perhaps not so good, but it would work just 
fine. If you choose subnets with prefixes longer than 64 where all those 
bits are non-zero, then you cannot use embedded-RP with an RP address 
belonging to that subnet. So while I don't understand your constraint as 
written in the draft, it might be worth pointing out what I wrote above.

In general it might be good to say that when choosing addresses for 
routers, it might be worth considering whether the addresses work with 
embedded-RP. If you might want to use embedded-RP where that router is 
an RP, then it should have at least one "embeddable" address.

I suppose in many cases (at least AFAIK) people would use an additional 
loopback address on a router as RP address. This makes it easy to move 
the RP to another router. Especially for embedded-RP this is useful, 
since you don't want to change the group addresses applications use just 
  because you want to move the RP. This loopback addresses then need to 
be "embeddable". In this case, it doesn't matter what addresses the 
router uses on the physical interfaces.

Stig

---

From: "Gunter Van de Velde (gvandeve)" <[email-masked]>
Date: Thu, 16 Mar 2006 09:57:11 +0100

Hi Stig,

Thanks for the review and reading the document. Please see inline:

>used with embedded-RP. For each of those you have 32 bits for multicast 

That is exactly what we wanted to mention. We will revise the text.

>longer than /64. This is perhaps not so good, but it would work just fine. 
>If you choose subnets with prefixes longer than 64 where all those bits 
>are non-zero, then you cannot use embedded-RP with an RP address belonging 
>to that subnet. So while I don't understand your constraint as written in 
>the draft, it might be worth pointing out what I wrote above.

The above text is pointing towards an awareness (maybe the word 
'constraint' was too strong).
If one makes a subnet longer as 64 bits, that the all '0' should/may be avoided
as there is risk that one of the addresses could in that case overlap with 
an embedded-RP address. And yes, it will/should still work as unicast IPv6 
address, but i think it is not
very good practice to have addresses used that have may have double 
usage/meaning.

I also see the point you are making and it makes a good addition to the draft.

>embedded-RP. If you might want to use embedded-RP where that router is an 
>RP, then it should have at least one "embeddable" address.
>
>loopback address on a router as RP address. This makes it easy to move the 
>RP to another router. Especially for embedded-RP this is useful, since you 
>don't want to change the group addresses applications use just  because 
>you want to move the RP. This loopback addresses then need to be 
>"embeddable". In this case, it doesn't matter what addresses the router 
>uses on the physical interfaces.

I agree. Although the above text is more a design recommendation which is
not the main focus of this draft.

Thanks again,
G/

---

From: "Gunter Van de Velde (gvandeve)" <[email-masked]>
Date: Thu, 16 Mar 2006 10:16:26 +0100

Hi John,

Thanks for the review and reading the text. See inline

>period.  Since your document is implementation-oriented, this might be worth

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

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

>comes at the cost of complexity for the network operations team.

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

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

>if that met their needs.  So, again, not sure it should go in, but it is

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

>big difference, in practice.

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

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

tx. will adjust

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

>manually in the DNS?  Why not give them a simpler, manual address that would

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

---

From: Tim Chown <[email-masked]>
Date: Thu, 16 Mar 2006 12:01:19 +0000

> as its implementation oriented, but not lead as long as the ARIN decision 

I've been following this through some Internet2 contacts, and it seems
to have dragged for at least 12 months so far.  So if it does happen, I
wouldn't bet on it being soon.    I think the draft can say no such
process exists now for PI, but that some scheme may emerge over time.
 
> in IPv6 due to the aggregation principles. I'm not sure if this has been 

I think a number of these issues in IPv6 space were investigated when
Christian Huitema's 'what can we do today' multihoming proposal was discussed
in the days of the multi6 WG.  I think the problem is still outstanding.

> >Suppose a site has a /47 because they are large enough to warrant it.  
> 

Ideally if I needed to use local addresses and needed more than a /48 I
could use an aggregated prefix.  But the ULA spec doesn't cater for that.
The Centralised ULA spec could, but I think that one's dead in the water?
 
> I will leave the other sections for Tim as he edited the study.

OK, but you have the edit token :)
 
> >*) In 5.1, can you include an estimate of the number of subnets too?

There are around 1,500 hosts in around 20 IPv4 subnets ranging from /23
down to /28 size.   Keeping IPv4 subnets shrinkwrapped to host counts is
an IPv4-specific pain.

> >If so, you might note that here as a practical consideration.

We follow the guidelines of the NAP draft, and thus consider all hosts
to be globally addressed and use filtering at appropriate borders to
constrain access.   Modern campus switch-router equipment enables such
filtering to be done very efficiently on an intranet basis too.  I do
appreciate it's a method some people use now in IPv4, but my understanding
of the NAP ethos is to globally address all nodes.   I wouldn't want
the draft to be derailed by some religious aside though :)

> >the convenience of having each school on a /56 yields other benefits (than

That was based on the organisational considerations of the university.
Off hand there are I think around 20 schools; thus a /56 per school 
seemed appropriate.   We felt that a common allocation size per school
would also simplify management, and a /56 left lots of headroom for
existing schools to grow.   The other 'nice' options would have been a 
/52 or a /60, which seemed excessive or restrictive respectively.

> >manually in the DNS?  Why not give them a simpler, manual address that 

We do that for server systems, e.g. DNS servers on ::53 (because you can :),
and in the longer run we plan to use DHCPv6, because our administrators
like to be able to control address assignment, and it does simplify
management (hosts running RFC3041 - currently by default all XP systems -
are a pain from that perspective).   We don't see much NIC swapout actually;
most modern laptops have embedded NICs rather than PCMCIA ones, though 
maybe we'll see a mini resurgence of that with 802.11a cards.   But yes,
long term DHCPv6, and infrastructure servers manually assigned.

Thanks again for the detailed review and good questions.

Tim

---

From: [email-masked]
Date: Thu, 16 Mar 2006 14:42:13 +0000

> process exists now for PI, but that some scheme may emerge over time.

	the I2 folks are pretty good, but it is possible to get the
	information directly from ARIN, indeed, ARIN seeks for direct
	input.

	this issue is on the agenda for the next ARIN mtg (08-13apr2006)
	in Montreal. http://www.arin.net/announcements/20060313.html
	and one does not have to physically be present to participate:
	http://www.arin.net/announcements/20060310.html ... 

	from my cursoury review of the mailing list discussion, there is
	strong member desire for PI space... and policies are set by the
	members.

--bill

---

From: Pekka Savola <[email-masked]>
Date: Sun, 19 Mar 2006 16:42:24 +0200 (EET)

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

Overall, I liked this doc.  This would seem to be the logical place to 
put in the critical bits (if any) from Jordi's point-to-point doc, as 
well.

A few small comments,

- in section 2.1, "allocation" should be "assignment"
- in secyion 2.4.1, the HD-ratio for v6 is for *sites* not addresses 
like in v4
- the embedded-RP part was already commented on.
- in section 4.3, there's an uppercase SHOULD for CGA regeneration, 
but this kind of doc shouldn't use uppercase keywords
- in section 4.3, CGA's aren't really indistinguishable, because if 
you know (or guess) the public key of the sender, you can verify who 
it belongs to.. but for many purposes, these have similar properties.
  - section 4.4, as above, you shouldn't need to mention embedded-RP 
reserved addresses.  These are not reserved by default: it's the local 
admin's decition whether to put an RP at one of those interface-ID's, 
so they be used freely (though I'd advise that hosts still shouldn't 
use those).

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: "Gunter Van de Velde (gvandeve)" <[email-masked]>
Date: Tue, 21 Mar 2006 17:00:36 +0100

At 16:42 19/03/2006 +0200, Pekka Savola wrote:
>>Resend of original message as i apparently did not reach the overall 
>>v6ops alias.
>....
>
>Overall, I liked this doc.

That is always nice to hear :-)

>This would seem to be the logical place to put in the critical bits (if 
>any) from Jordi's point-to-point doc, as well.
>
>A few small comments,
>

ok

>- in secyion 2.4.1, the HD-ratio for v6 is for *sites* not addresses like 
>in v4

ok

>- in section 4.3, there's an uppercase SHOULD for CGA regeneration, but 
>this kind of doc shouldn't use uppercase keywords

ok

>- in section 4.3, CGA's aren't really indistinguishable, because if you 
>know (or guess) the public key of the sender, you can verify who it 
>belongs to.. but for many purposes, these have similar properties.
> admin's decition whether to put an RP at one of those interface-ID's, so 
> they be used freely (though I'd advise that hosts still shouldn't use those).

the last sentence between brackets is the awareness we wanted to achieve.

Thanks again for the reading the document and for the review comments.

Brgds,
G/