See below.
Dave Taht wrote:
On Thu, Mar 22, 2012 at 3:50 PM, Brian E Carpenter
<[email protected] <mailto:[email protected]>> 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
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
