Re: IPv6 Unicast Address Assignment Considerations

[Tim Chown <tjc@ecs.soton.ac.uk>]

On Thu, Mar 16, 2006 at 10:16:26AM +0100, Gunter Van de Velde (gvandeve) wrote:
> 
> At 18:12 7/03/2006 -0800, John Spence wrote:
> 
> >*) 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.

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

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.

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

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.

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

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

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

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.

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

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