On 2009-06-24 06:31, Arifumi Matsumoto wrote: > Hi, > > On 2009/06/23, at 16:19, Brian E Carpenter wrote: > >> 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. > > This creates a black hole not only for Site A, but also any other sites > in the Internet, if ULA is visible in DNS. > So, preventing a black hole only for ULA site does not suffice.
True. Which shows that our scope model is too simple for the real world. > Another point is that using longest match to distinguish between ULA and > non-ULA(GUA) is not a good idea, considering the possibility of expansion > of GUA's space with the deployment of IPv6, and the possibility of > creation of new IPv6 unicast address block somewhere near ULA's address > block. Same comment. > Surely, configuring local policy is the best way to implement site local > policy. Here, however, we have to settle the default universal policy > anyhow. I agree with that; I would just like to see 3484bis containing operational warnings (e.g. "configure local policy if using a ULA prefix for VPN; never put ULA in global DNS"). Our experience is that 3484 has serious operational implications. Brian > > Kindest regards, > >> >> 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 > > > -- > Arifumi Matsumoto > Secure Communication Project > NTT Information Sharing Platform Laboratories > E-mail: arif...@nttv6.net > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
