Re: RFC 3484 Section 6 Rule 9

Hi Brian,

the only adverse effect of adopting choice 3 with N=32 is that
in a large site with larger than /32 address block, the optimal
route is not always chosen.

For such a case, site admin should have a mechanism to configure
policy table of hosts in his site, rather than configure N.
Because changing N means changing destination address selection
behavior for all the destinations in the Internet.

Kindest regards,

Arifumi Matsumoto

On 2009/06/22, at 18:48, Brian E Carpenter wrote:

> Hi,
>
> Sorry about the late reply. I agree with this (that is,
> choice 3 in section 2.6 of draft-arifumi-6man-rfc3484-revise-01).
>
> Regards
>   Brian
>
> On 2008-06-07 03:01, Arifumi Matsumoto wrote:
>> Let me switch to 6man ML.
>> # Brian, thank you for redirection ;)
>>
>> Regarding this issue of RFC 3484 section 6 rule 9,
>> let me give you my two cents, which is conditional longest
>> matching rule application.
>>
>> When the length of matching bits of the destination
>> address and the source address is longer than N,
>> the rule 9 is applied. Otherwise, the order of the
>> destination addresses do not change. (For DNS-RR)
>>
>> The N should be configurable and I guess it should be 32
>> by default. This is simply because the two sites whose
>> matching bit length is longer than 32 are probably
>> adjacent.
>>
>> Regards,
>> Arifumi Matsumoto
>>
>> On 2008/06/04, at 13:20, Brian E Carpenter wrote:
>>
>>> Joe,
>>>
>>>> It seems to me that direct assignment could quite possibly become  
>>>> the
>>>> default for small IPv6 sites in the ARIN region. IPv6 uptake to
>>>> date has
>>>> been so tiny that I don't think anybody can predict what behaviours
>>>> will
>>>> become prevalent if/when IPv6 takes off.
>>> We can't predict how economic actors will choose to act. What we can
>>> predict
>>> is catastrophe if ten or 100 million sites attempt to push /48
>>> advertisements
>>> out into BGP4. It would be highly irresponsible of any registry to
>>> pursue
>>> a policy that leads to such a result, until we have a technical
>>> solution
>>> to the resulting scaling problem. It's exactly because we don't have
>>> such
>>> a solution that the IPv6 design model is PA.
>>>
>>> I'm not shocked at the notion of a few hundred thousand early
>>> adopters of
>>> IPv6 getting PI prefixes. But that's a very different matter than
>>> millions.
>>>
>>> (This remains directly relevant to the subject of this thread. The
>>> infamous Rule 9 exists, right or wrong, because of PA addressing
>>> in IPv6.)
>>>
>>>   Brian
>>> _______________________________________________
>>> IETF mailing list
>>> IETF@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ietf
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

--
Arifumi Matsumoto
   Secure Communication Project
   NTT Information Sharing Platform Laboratories
   E-mail: arifumi@nttv6.net