Hello, +1 for Brian's statement : ULA within same /48, prefer ULA.
For ULA not within same /48 : Please do not forget VPN ! In the IPv4 world, numerous devices, with private address space, Communicate through site-to-site VPN's. I'd assume this is equivalent to "ULA not in same /48". How could an end-device decide whether or not VPN is in place ? Wouldn't it be preferable to let "name resolving" decide which address to return to a client ? And if name resolving returns ULA, let end-device use ULA as well. (If there is no VPN in place, it would be a configuration error in the name resolving infrastructure) That way, network admins decide centrally, trough name resolving, how some party is can be reached. Any errors there would be name resolving which can, through DNS, be centrally solved. As opposed to some "smart" algorithm on end nodes that mistakingly choses the wrong address (and requiring some update on all of them ...) Kind regards, Marc Lampo -----Original Message----- From: Dave Thaler [mailto:[email protected]] Sent: 17 March 2012 07:23 AM To: Brian E Carpenter; Hemant Singh (shemant) Cc: [email protected]; Brian Haberman; Arifumi Matsumoto; Bob Hinden Subject: RE: ULA scope [draft-ietf-6man-rfc3484-revise-05.txt] 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. 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 --------------------------------------------------------------------
