Re: [homenet] #4: Use of ULAs

[Ray Hunter <[e-mail]>]

See below.

Dave Taht wrote:
> On Thu, Mar 22, 2012 at 3:50 PM, Brian E Carpenter 
> <[e-mail] <mailto:[e-mail]>> wrote:
>
>     On 2012-03-22 12:33, homenet issue tracker wrote:
>     > #4: Use of ULAs
>     >
>     >  CN1 in the -02 text says ULAs should be provisioned by default.
>      Do we
>     >  agree?
>
>     Yes, by the CER (MUST).
>
Firstly are we stating *the* CER or *a* CER? What happens when there is 
more than one CER? Does that then need an election process? And when the 
"winner" disappears because you've changed providers or router hardware 
or the router fails, all ULA's also get renumbered?
>
>     It's much less clear for all other routers on site. I would prefer
>     that
>     no other router provisions a ULA prefix if the CER has already
>     delegated
>     one.
>
>
> Since it is nearly impossible to learn a subnet prefix that is unused 
> unless all devices share a routing protocol, I have generally 
> preferred to generate unique ULAs per routing device.
>
Generating a ULA independently per router is potentially going to bring 
problems with the new RFC3484-revise as they'll almost certainly have 
different Global ID's (and thus a different /48 prefix), so ULA will not 
be preferred for communication between nodes connected to different routers.



Sometimes it's useful to take a complete opposite view to the way you've 
been thinking, and work though the consequences.

What about going to the extreme and giving up on central/coordinated 
control of a single ULA /48 Global ID throughout the Homenet?

What about tolerating static prefix assignments (for sensor networks)? 
We allow static individual IPv6 address assignments to end nodes as well 
as SLAAC, so why not tolerate statically assigned /64 prefixes? Even in 
Appletalk, the much vaunted champion of autoconfiguration, a network 
manager had to manually assign the network number range to at least one 
seed router in an extended network.


How about:

- multiple ULA /48 Global ID's within a single Homenet is not considered 
an "error"

    Every router may generate it's own ULA /48 Global ID independently, 
or use an existing one generated by another router.
    That gets rid of any time-ordering of installation, net splitting or 
net fusing issues.
    Also allows the electrician to set up his sensor network before the 
ISP arrives (or vice versa)

- routers should configure up one /64 prefix per interface for each ULA 
/48 Global ID present in the Homenet.

   This could use the same prefix assignment mechanism as PA addresses 
learned via DHCPv6 PD from the ISP.
   Each router could perhaps act as the seed router for its own ULA /48 
Global ID in the prefix assignment process.
   All of the ULA /48 Global ID's would be distributed throughout the 
complete Homenet network, so that if a router
   is added to the Homenet it may be an additional/new ULA /48 Global ID 
in the Homenet network,
   but the original ULA /64 prefixes derived from other routers' ULA /48 
Global ID's will still be available on all interfaces.
   That copes with mobile nodes and routers that are bought and sold. It 
also copes with failure of a single "master" router.

- every end node and router using RFC3484-revise should also configure 
up a ULA address for every ULA /64 prefix present.

   Dumb sensors may simply ignore 3484-revise (it's only informational) 
and always prefer ULA.
   End nodes using 3484-revise would now have a native ULA address from 
each ULA /48 Global ID,
   and therefore the proposed new rule in RFC3484-revise of source /48 
ULA = destination /48 ULA would
   come into play and ULA would always be preferred for local 
communications.

   You may end up with two or more usable ULA pairs between any two nodes,
   but is that a problem when we want high availability, and provider 
independence?

- prefix assignment autoconfiguration should avoid assigning prefixes 
that conflict with statically configured prefixes
   (e.g. hard coded sensor networks).

   That may require changing the tie-break mechanism in e.g. 
draft-baker-homenet-prefix-assignment-01
   so that a router with a static /64 prefix assignment can veto all 
other routers who (accidentally)
   try to auto-assign the same /64 and thus cause a collision.

   So it would be the equivalent of Duplicate Address Detection, but at 
the /64 prefix level.


OK each end node and router would have lots of prefixes and addresses 
(possibly two or more per router in the homenet) but isn't that less 
problematic than trying to centrally gather the ULA /48 Global ID's in 
use and then distribute an updated RFC3484-revise policy table to all 
end nodes, or magically electing a master node to coordinate the choice 
of a single ULA /48 Global ID?


regards,
RayH