Kerry Lynn writes: > On Sat, Mar 17, 2012 at 2:22 AM, Dave Thaler <[email protected]> > wrote: > > Brian Carpenter writes: > > [...] > >> Let me be clear. If a local service has (for some reason) both a ULA > >> and a non- ULA global address, and the host has both, I think the > >> correct default behaviour is for the ULA address pair to be used. > > > > As I put into the doc, I don't think that's quite right. > > > > If both the source and dest ULAs are in the same /48 then I think the > > correct default is as you say (use ULA). > > > > If the source and dest ULAs are in different /48's then I think the > > correct default is instead to use the non-ULA global, since there's no > > guarantee of routability between different /48s. So unless configured > > otherwise, one has to assume it's far more problematic than a non-ULA > global. > > > Do you mean "no guarantee of symmetric routability"? The fact that the > packet arrived in the first place seems to indicate earlier policy choices > (e.g. > the sender may not have a non-ULA global address, and the two /48s already > seem to share a common definition of "site"). > > I am still relatively new to homenet and I am surely missing a lot of > background. Has anyone discussed dealing with multiple /48 ULA prefixes > in a single site?
I would like to second Kerry. It is a surprise to me that ULA addresses are not by default routable within the site. I can easily imagine a number of LLN border routers which autonomously allocate different ULA prefixes for use within their individual LLN subnets. Meeting a ULA address outside the local prefix will cause the LLN node to forward its IP packets to the default gateway (border router) of the LLN subnet. This way packets can travel between LLN subnets using normal routing with long-term stable ULA addresses. We need the stable addresses for control-style applications in LLNs. Obviously it requires a routing protocol in the (homenet) LAN but are there other issues? Thanks, Anders > > > You'll find the above logic in the current 3484bis draft. > > > > -Dave > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > [email protected] > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > _______________________________________________ > homenet mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/homenet -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
