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

From: Brian E Carpenter <[email-masked]>
Date: Mon, 22 Jun 2009 11:01:14 +0100

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.)

   Brian

---

From: Arifumi Matsumoto <[email-masked]>
Date: Mon, 22 Jun 2009 19:59:47 +0900

Hi,

> 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 ?

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 ?

--
Arifumi Matsumoto
   Secure Communication Project
   NTT Information Sharing Platform Laboratories
   E-mail: [email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 23 Jun 2009 08:19:54 +0100

> 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.

> 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

---

From: Arifumi Matsumoto <[email-masked]>
Date: Wed, 24 Jun 2009 14:31:01 +0900

Hi,

> 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,

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 24 Jun 2009 08:23:55 +0100

> 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.

> non-ULA(GUA) is not a good idea, considering the possibility of expansion

Same comment.

> policy. Here, however, we have to settle the default universal policy

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

---

From: Aleksi Suhonen <[email-masked]>
Date: Mon, 29 Jun 2009 13:34:14 +0300

> True. Which shows that our scope model is too simple for the real world.

While writing my suggestion on a new address selection algorithm, I've 
tried to tackle this problem too. How can a machine react to different 
non-link-local scopes correctly if the machine can't even hope to 
identify them?

The best I've come up with so far is as follows (and I think it could be 
applicable to any other rfc3484 revision):

If the autoconfiguration mechanism supplies a default route for the 
address, it is a global scope address. Otherwise it is only site or link 
local.

Same goes for static configuration, although it will probably be harder 
for the machine to recognize which address a staticly configured default 
route is for in the general case...

RFC3442 and RFC4191 allow autoconfiguring more specific routes too. Site 
scoped addresses should be supplied with routes to the address space 
they are usable with. Obviously we'd need an IPv6 equivalent of RFC3442.

(DISCLAIMER:)
How or whether the address selection algorithm uses these more specific 
routes is IMO less relevant than the fact that it could recognize 
address scope from their presence or absence...

-- 
	Aleksi Suhonen
	Department of Communications Engineering
	Tampere University of Technology