Subject: Re: ULA scope [draft-ietf-6man-rfc3484-revise-05.txt]
From: Arifumi Matsumoto <[email-masked]>
To: Brian E Carpenter <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Brian Haberman <[email-masked]>, Bob Hinden <[email-masked]>, Dave Thaler <[email-masked]>
Date: Sat, 17 Mar 2012 09:29:37 +0900
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>

Brian,

2012/3/17 Brian E Carpenter <[email-masked]>:
> On 2012-03-16 23:30, Arifumi Matsumoto wrote:
> ...
>> 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 ?
>
> I would expect it to be preferred as a result of longest match; I would
> not expect it to be a special case in the default policy for global
> scope addresses, if that is the question.

ULA-to-ULA will not be preferred, because ULAs are assigned lower
precedence value in the policy table than those of IPv4 and IPv6
global addresses.

Best,

>>>> 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.
>
> That's an implementation method. I think Dave's proposed rule is
> correct.
>
>    Brian
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------