Dave, On 2012/03/01, at 11:20, Dave Thaler wrote:
>> -----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. Rather, my question was about the design choice. Regarding the design of ULA and how to use the ULA, can we agree that ULA-to-ULA communication within the same /48 prefix is not always preferred over other communications using IPv4 or IPv6 global addresses ? >> 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. My suggested answer for this was to use macros, which can be added/deleted by a user, and interpreted as the actual prefix attached to the hosts. Best regards, -- Arifumi Matsumoto NGN System Architecture Project NTT Service Integration Laboratories E-mail: [email protected] TEL +81-422-59-3334 FAX +81-422-59-6364 -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
