Re: ULAs in draft-arifumi-6man-rfc3484-revise-01

[Arifumi Matsumoto <arifumi at nttv6.net>]

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.

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.

Surely, configuring local policy is the best way to implement site local
policy. Here, however, we have to settle the default universal policy  
anyhow.

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: arifumi at nttv6.net