Re: [homenet] #4: Use of ULAs

[Dave Taht <[e-mail]>]

On Wed, Mar 28, 2012 at 12:44 AM, Ray Hunter <[e-mail]> wrote:

> **
> See below.
>
>
> Dave Taht wrote:
>
> On Thu, Mar 22, 2012 at 3:50 PM, Brian E Carpenter <
> [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.
>
>
As I'm arguing with a draft that I haven't read, I'm a little at a loss.

Will certainly have different global ids.

ULA should be preferred for communication between nodes connected to
different routers if they are both in the ULA space. Consider linking two
offices via vpn, for example....

Other arguments are other autonomous devices (like devices that have
arbitrary numbers of subnets, like routers... your car...) or sensor
networks...

(01:09:33 AM) dtaht: There simply aren't enough routes in a homenet to fill
a routing table inside the home
(01:09:43 AM) dtaht: even if every router chooses a unique ULA




>
> 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?
>
>
Love it.


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


>    Every router may generate it's own ULA /48 Global ID independently, or
> use an existing one generated by another router.
>

Works for me.


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

SLAAC generally works fine.


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


> - every end node and router using RFC3484-revise should also configure up
> a ULA address for every ULA /64 prefix present.
>
>
 is this the exact draft to which you are referring?

http://datatracker.ietf.org/doc/draft-ietf-6man-rfc3484-revise/

  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.
>
>
I think we are in disagreement here.

But I'm going to stop now, resume the conference, and play catchup on this
draft later.

  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
>



-- 
Dave Täht
SKYPE: davetaht
US Tel: [phone]
http://www.bufferbloat.net