RE: ULA scope [draft-ietf-6man-rfc3484-revise-05.txt]

[Dave Thaler <[e-mail]>]

> -----Original Message-----
> From: Arifumi Matsumoto [mailto:[e-mail]]
> Sent: Thursday, February 23, 2012 10:14 PM
> To: Brian E Carpenter
> Cc: Dave Thaler; Chris Grundemann; [e-mail]; 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