On 2009-06-22 11:59, Arifumi Matsumoto wrote:
> Hi,
>
> On 2009/06/22, at 19:01, Brian E Carpenter wrote:
>
>> Hi,
>>
>> Section 2.3 of draft-arifumi-6man-rfc3484-revise-01 says:
>>
>>> 2.3. To change ULA address scope to site-local
>>>
>>> RFC 5220 Section 2.1.4, 2.2.2, and 2.2.3 describes address selection
>>> problems related to ULA. These problems can be solved by changing
>>> the scope of ULA to site-local.
>>
>> This change will also create a new problem, for sites that configure a
>> VPN to another partner site using ULAs on both sites, so that ULA-to-ULA
>> traffic can use the VPN. In this case ULA=global and longest match may
>> well be the correct choice. If we change to ULA=site-local, then there
>> must be a note that sites wishing to use ULAs for VPN communications
>> will need to configure local 3484bis policy accordingly. (This is
>> really the inverse of what is stated in RFC 5220.)
>
>
> I failed to see why we need to change policy when ULA=site-local.
> Could you please elaborate on this ?
Yes, it is a bit tricky. If Site A generates addresses using prefix ULA1,
and site B generates addresses using prefix ULA2, there are three cases:
1. No route exists between Site A and Site B for ULA1 and ULA2 addresses.
In that case, if both ULA1 and ULA2 are classified as site-local,
and if ULA addresses are visible in DNS, choosing site-local scope
will create a black hole, just like global scope. The problem is DNS
configuration, but it can be avoided by local policy that treats *only*
ULA1 as site-local on site A, and only ULA2 as site-local on site B.
2. Routing over a VPN between ULA1 and ULA2 is present. In that case
site-local scope will work fine.
3. Routing works in one direction only. Only mentioned for completeness,
obviously a configuration error.
>
> And, if we adopt ULA=global scope and longest match with N=32 set,
> the case 2.1.4 in RFC 5220, ULA can be chosen for the source address
> to connect a server in the Internet ?
I agree. So I'm not against the change, but my case 1 above remains as
a problem case. Only ULA prefixes that are locally routeable should
be treated as site-local; any others could be black holes. I think this
needs to be local policy.
BTW, I think we have a deeper problem in the scope rules, see
draft-carpenter-behave-referral-object-00.txt.
Brian
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
