> -----Original Message----- > From: Arifumi Matsumoto [mailto:[email protected]] > Sent: Thursday, February 23, 2012 10:14 PM > To: Brian E Carpenter > Cc: Dave Thaler; Chris Grundemann; [email protected]; Brian Haberman; Bob > Hinden > Subject: Re: ULA scope [draft-ietf-6man-rfc3484-revise-05.txt] > > Dave, > > in Example section of draft-ietf-6man-rfc3484bis-00.txt, I found the response > to > this issue of ULA scope. > > 10.6. Configuring ULA Preference > ... > Since ULAs are defined to have a /48 site prefix, an implementation > might choose to add such a row automatically on a machine with a ULA. > > It is also worth noting that ULAs are assigned global scope. As > such, the existence of one or more rows in the prefix policy table is > important so that source address selection does not choose a ULA > purely based on longest match: > > Candidate Source Addresses: 2001:db8:1::1 or fd11:1111:1111:1::1 > Destination Address List: ff00:1 > Result: 2001:db8:1::1 (prefer matching label) > > > IMO, this implicit specification causes several problems. > > First of all, if you leave it to implementation, this creates an > interoperability > problem. In the sense that a site administrator, an application developer, a > network designer, have to take care of the nodes with different address > selection behavior.
Are you arguing it should be mandatory, not optional? (I'm guessing so based on the previous discussion of "macros" in the table.) But still, you have to take care of nodes with different address selection behavior anyway if you allow heterogeneous hosts, since you'll have a) hosts that don't do RFC 3484 b) hosts that do RFC 3484 c) hosts that do 3484bis And even within a category above, the IPv4 source address selection behavior will vary since that's not specified. At best you can argue to minimize the problem as much as possible, but you can't make it go away. > Second, > when a user configures his policy table, the configured table is overwritten > by > this implementation dependent policy injection behavior ? > Can the user suppress this behavior of policy injection ? > This issue should arise also when a policy distributing mechanism is ready. Good questions. Do you have suggested answers to those questions? I might throw out a strawman of: Any automatic rows added by the implementation as a result of address acquisition MUST NOT override a row for the same prefix configured via other means. That is, rows can be added but never updated automatically. An implementation SHOULD provide a means for an administrator to disable automatic row additions. -Dave -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
