Subject: Re: [BEHAVE] NAT66 - fc01::/48 a dummy ULA for the dummies

From: Rémi Després <[email-masked]>
Date: Mon, 01 Dec 2008 11:07:44 +0100

Brian E Carpenter  -  le (m/j/a) 11/28/08 9:33 PM:
> On 2008-11-29 06:22, Rémi Després wrote:
>
> Margaret Wasserman  -  le (m/j/a) 11/28/08 3:18 PM:
>   
>>> IMO, using site local addresses (or the site local prefix) for
>>> addressing behind a NAT would be a huge mistake.
>>>       
>> I don't see why.
>>     
Note that although I don' t see why this would be "a huge mistake", I 
don't propose to "re-legitimize site local address usage."

I just propose to define a *standard and simple way* to create a 
"private prefix".
This is for those who want to isolate their internal plan from the 
outside (to avoid difficult renumbering), and that don't manage their 
home gateway. 
 
Without a simple and stable native prefix, they would have to create a 
ULA, right?
For this, according to RFC 4193:
"1) Obtain the current time of day in 64-bit NTP format [NTP]
2) Obtain an EUI-64 identifier from the system running this   
algorithm.  If an EUI-64 does not exist, one can be created from a 
48-bit MAC address as specified in [ADDARCH].  If an EUI-64  cannot be 
obtained or created, a suitably unique identifier,  local to the node, 
should be used (e.g., system serial number).
 3) Concatenate the time of day with the system-specific identifier in 
order to create a key.
4) Compute an SHA-1 digest on the key as specified in [FIPS, SHA1]"

IMHO, this is far too complicated for a residential user:
Time of the day when? (What if my system is reinitialized?)
Local to which node? (What if I change my CPE?)
>> I know of course that site local addresses have been deprecated by RFC
>> 3879.
>> But scope identifiers were indeed an unnecessary pain that to needed to
>> be relieved
>> But that is exactly the reason why ambiguous address space causes
>> problems that *cannot* be fixed, and exactly the reason why ULAs
>> are better for all purposes than site-local. We cannot tell by looking
>> at a site-local address that reaches us whether it is in fact local,
>> or whether it came by accident from another scope (via a VPN bypassing
>> normal routing, or via a faulty referral of some kind). Whereas a ULA
>> that reaches us incorrectly is immediately known to be unroutable.
>>
>> In other words ULAs are much more resistant to misconfiguration or
>> bad protocol design than site-locals. I'm strongly against legitimising
>> their use again.
>>     
Not clear to me. They can be mis-configured too.

Personally, I never met any problem with private IPv4 addresses 
belonging to another network entering a site I knew.

Note also that  IETF prohibiting to use a ULA with a non random Global 
ID will not prevent some users to do it if they want to.
Better standardizing a value, or at least suggesting one, than letting 
every one pick its own.
IMHO, fc01::/48 would be a natural choice for those who want one (a null 
Global ID).

Regards,
RD

_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Pekka Savola <[email-masked]>
Date: Mon, 1 Dec 2008 14:55:08 +0200 (EET)

On Mon, 1 Dec 2008, Brian E Carpenter wrote:
> On 2008-12-01 07:28, Keith Moore wrote:
>> Iljitsch van Beijnum wrote:
>>> On 28 nov 2008, at 21:33, Brian E Carpenter wrote:
>>>
>>>> Whereas a ULA
>>> Unfortunately, that's not the case. When ULAs were under discussion, I
>>> repeatedly asked the question whether ULA routability was to be a
>>> fundamental aspect of their design, or something imposed by the
>>> limitations of the routing infrastructure. As far as I remember, I never
>>> got a satisfactory answer to that.
>>>
>>> So this means that when the RRG magically makes routing scale, some
>>> people will probably want to insert their ULAs into the routing system /
>>> routing overlay system and problems will ensue.
>>
>> ULAs are certainly not "known to be unroutable".  For that matter,
>> global PA addresses are not "known to be routable".
>
> Not by the host, I agree. But the site routing system *does* know,
> and will drop or forward packets accordingly. This is not the case
> if the routers see FEC0::1 and that happens to exist locally - the packet
> will be delivered, exactly the problem we have today with 10.1.1.1
> and the like.

Not sure whether you're talking of destination or source addresses, or 
both.

Lots of sites out there forward a lot of packets out to their ISP 
today. For example, if a site uses 10.0.x.0/24, all packets to the 
rest of 10/8 are usually forwarded out to the ISP using a default 
route.  As a source address, all of these addresses may leak to the 
ISP.

The same is going to come up with ULAs, luckily these should at least 
be less ambiguous.

The argument that "the site routing system *does* know" doesn't seem 
to be true in practise or we're thinking of different things.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 1 Dec 2008 08:36:44 -0500

Hi Remi,

On Dec 1, 2008, at 5:07 AM, Rémi Després wrote:
> outside (to avoid difficult renumbering), and that don't manage  
> their home gateway. Without a simple and stable native prefix, they  
> would have to create a ULA, right?
> 48-bit MAC address as specified in [ADDARCH].  If an EUI-64  cannot  
> be obtained or created, a suitably unique identifier,  local to the  
> node, should be used (e.g., system serial number).
> 3) Concatenate the time of day with the system-specific identifier  
> in order to create a key.

It is not our expectation that a residential user will _ever_ generate  
a ULA prefix by hand.  In fact, most residential users won't know that  
they have a ULA or what a ULA is...  Their home gateway will generate  
a ULA for them and provide the ULA prefix in RAs on the local network  
(or via DHCPv6).  This is the IPv6 equivalent of allocating net 10  
addresses via DHCP on the local network.

Enterprise network administrators will probably choose to use an  
online tool or a script, like this one:  http://www.sixxs.net/tools/grh/ula
> belonging to another network entering a site I knew.

It is a pretty typical user experience to join another net 10 network  
(such as a corporate VPN) and lose access to nodes on the local  
network (such as your local printer).  There are a lot of reasons why  
this might happen, but one of them is that both networks are using net  
10 and the VPN is set-up so that net 10 is routed over that interface.
>
> Note also that  IETF prohibiting to use a ULA with a non random  
> Global ID will not prevent some users to do it if they want to.
> Better standardizing a value, or at least suggesting one, than  
> letting every one pick its own.
> IMHO, fc01::/48 would be a natural choice for those who want one (a  
> null Global ID).

If you want to allocate a global ULA prefix for this purpose, you  
should probably raise the issue in 6man, as it isn't really a behave  
topic.

Margaret

---

From: Rémi Després <[email-masked]>
Date: Mon, 01 Dec 2008 14:52:46 +0100

Margaret Wasserman  -  le (m/j/a) 12/1/08 2:36 PM:
> , 2008, at 5:07 AM, Rémi Després wrote:
>> home gateway. Without a simple and stable native prefix, they would 
>> have to create a ULA, right?
Then, how stable is the  ULA is uncertain (effect of a reinitialization, 
change of CPE etc.), IMHO an undesirable property.

> 10 and the VPN is set-up so that net 10 is routed over that interface.
Yes, making some local devices and/or applications accessible from the 
outside has to be easy.
IMHO, it has to be done with *global* addresses, which are routable 
across the Internet.
Thanks to IPv6, complex mechanisms like STUN, TURN etc. will no longer 
need to be used for this.

> should probably raise the issue in 6man, as it isn't really a behave 
As long that Behave doesn't state that this is forbidden, I agree.

Regards,
RD

---

From: Keith Moore <[email-masked]>
Date: Mon, 01 Dec 2008 09:17:47 -0500

> I just propose to define a *standard and simple way* to create a

sure, but what you are proposing creates ambiguous addresses, which are
known to cause problems for the network and for applications.

> Local to which node? (What if I change my CPE?)

Users aren't expected to implement this themselves, any more than any
other protocol that IETF defines.  However, this algorithm can be
implemented in a router (say via its web interface), or on a separate
web page (maybe provided by the ISP), or whatever.

Imagine a CPE router with an option

[ ] advertise a ULA prefix for local use
    enter your ULA prefix here: [                      ]
    If you don't already have a ULA prefix for your network, you may
    generate one by pressing this button: [Generate ULA Prefix]

it doesn't take much code to implement this.

> belonging to another network entering a site I knew.

Trust us.  We have.  Just because something works for some people in
isolation does not mean it works well for the entire network.

> Better standardizing a value, or at least suggesting one, than letting

Exactly the opposite is true.  Letting every user pick his own address
makes for far less potential for collisions between networks even if
some users pick poorly.

Keith

---

From: Rémi Després <[email-masked]>
Date: Mon, 01 Dec 2008 15:46:33 +0100

Keith Moore  -  le (m/j/a) 12/1/08 3:17 PM:

Rémi Després wrote:

On this, please see my answer to Margaret.

Sure, but describing the problem we talk about before imposing
additional complexity to all is good practice.

Your description will be welcome to see where it applies and where it
doesn't.

My proposal is not dummy ULA for all, it's just dummy ULA for dummies
(that want to keep stable local addresses as they have today).

These dummies, of which I am concerning this point, never met any
problem with private addresses.

Different view on this point.

Regards,

RD

---

From: Keith Moore <[email-masked]>
Date: Mon, 01 Dec 2008 10:05:25 -0500

> problem with private addresses.

sorry, that's not correct.  the "dummies" (and all of us) suffer by
having a dysfunctional network that makes some kinds of applications
much more expensive, and much less reliable, than it would be if all
addresses were unique.

and the harm that the "dummies" do is not just to their own networks,
because applications have to run on their networks too, and we all pay
for the support costs to get applications running on dummies' networks.

> Different view on this point.

it's simple statistics.

Keith

---

From: Rémi Després <[email-masked]>
Date: Mon, 01 Dec 2008 16:20:33 +0100

Keith Moore  -  le (m/j/a) 12/1/08 4:05 PM:

It looks like you are not intending to explain the detailed nature of
the problem you are concerned with.

We have then exchanged as much as we could about this.

Regards,

RD

---

From: Keith Moore <[email-masked]>
Date: Mon, 01 Dec 2008 10:36:25 -0500

> the problem you are concerned with.

I've explained it about a hundred times already in years past.  Most
people here understand it already and many have the scars to prove it.

Keith

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 1 Dec 2008 11:25:06 -0500

Hi Remi,

On Dec 1, 2008, at 10:20 AM, Rémi Després wrote:

> It looks like you are not intending to explain the detailed nature  
> of the problem you are concerned with.

This problem is described, in general terms, in RFC 3879 (the one that  
deprecates site-local addresses).  I wrote a draft during the site- 
local deprecation discussions that went into more detail about the  
problems caused by site-locals.  It is long-since expired, but due to  
the wonders of Geoff Huston's Potaroo site, you can still find it  
here:  http://www.potaroo.net/ietf/all-ids/draft-wasserman-ipv6-sl-impact-02.txt 
.

Margaret

---

From: Rémi Després <[email-masked]>
Date: Mon, 01 Dec 2008 17:31:40 +0100

Margaret Wasserman  -  le (m/j/a) 12/1/08 5:25 PM:
> deprecates site-local addresses).  I wrote a draft during the 
> site-local deprecation discussions that went into more detail about 
> the problems caused by site-locals.  It is long-since expired, but due 
> to the wonders of Geoff Huston's Potaroo site, you can still find it 
> here:  
> http://www.potaroo.net/ietf/all-ids/draft-wasserman-ipv6-sl-impact-02.txt. 
>
Thanks, Margaret.
Il will read it carefully.
RD

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 1 Dec 2008 11:40:42 -0800

Christian Huitema wrote:
> ...
> If we want progress, we have to go beyond the reactionary attitude, and
> understand how we reconcile the two conflicting principles of end-to-
> end connectivity and selective isolation. Can we engineer selective
> isolation in the Internet while maintaining connectivity in all places
> where it is desired? Can we engineer that at the IP layer alone, or do
> we need to also evolve the naming system? What about TCP, IPSEC?

Which is exactly why this discussion needs to be done outside the 'solution
engineering' focused Behave WG. Asking people with a vested interest in
defining the behavior of a specific box to think about the widespread
architectural impact and related changes is guaranteed to create yet another
failure that needs to be worked around.

Tony

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 02 Dec 2008 09:44:12 +1300

Pekka,

On 2008-12-02 01:55, Pekka Savola wrote:
> Lots of sites out there forward a lot of packets out to their ISP today.
> For example, if a site uses 10.0.x.0/24, all packets to the rest of 10/8
> are usually forwarded out to the ISP using a default route.  As a source
> address, all of these addresses may leak to the ISP.

Yes, I was thinking about destination addresses. What you decsribe sounds like
lazy configuration, but it isn't harmful, because the ISP will
surely black-hole such packets (and if they don't, that's even more
lazy configuration). My concern is that internally, a packet with
a private-address destination *may* be delivered. But if that address
arrived by referral from another site, that delivery would be an error.

> The same is going to come up with ULAs, luckily these should at least be
> less ambiguous.

They're not ambiguous except by extraordinary bad luck (see many
past discussions about the negligible probability of ULA prefix collision).

> The argument that "the site routing system *does* know" doesn't seem to
> be true in practise or we're thinking of different things.

I believe it does know, unless it's misconfigured.

   Brian

---

From: Pekka Savola <[email-masked]>
Date: Tue, 2 Dec 2008 10:32:50 +0200 (EET)

> I believe it does know, unless it's misconfigured.

I believe what you're saying really is "the site routing system 
*could* know" or s/could/should/.  A lot of this depends on default 
configuration of these boxes and will come up with v6 as well.

FWIW, I'm not aware of any router which would include special 
treatment for ULAs in its default configuration or automatically when 
ULAs are being used (I'd like to be re-educated on this though).  As a 
result, the impact is that the site router doesn't know.

---

From: "Eric Klein" <[email-masked]>
Date: Tue, 2 Dec 2008 13:09:26 +0200

> failure that needs to be worked around.
This is why the original disussion was so broad (5 WGs each with an
interest) and then moved to BEHAVE. Personally I think this belongs in
Int-Area or other high level mailing list.

It is also possible that we should open this up as a new mailing list
(advertised in multiple places) and then when/if a consensus is reached we
can bring it back to the appropriate WG.

Eric

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 03 Dec 2008 09:56:45 +1300

On 2008-12-02 21:32, Pekka Savola wrote:
> I believe what you're saying really is "the site routing system *could*
> know" or s/could/should/.  A lot of this depends on default
> FWIW, I'm not aware of any router which would include special treatment
> for ULAs in its default configuration or automatically when ULAs are
> being used (I'd like to be re-educated on this though).  As a result,
> the impact is that the site router doesn't know.

Actually it doesn't matter - what matters is that a packet sent to
an off-site ULA generates a 'destination unreachable' response. If
that isn't configured on-site, most likely it will come from the
first ISP router; we have to assume that ISPs will get this right in
their configurations, even if user sites don't. But I agree - this is
a matter of correct configuration.

   Brian

---

From: Mark Andrews <[email-masked]>
Date: Wed, 03 Dec 2008 10:45:04 +1100

> a matter of correct configuration.

	Which is too late.  The message need to be generated by
	the border router that has a route back to node.

	ISP's can however help by counting and reporting ULA
	packet leaks.

	Mark
 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 03 Dec 2008 14:09:15 +1300

> 	the border router that has a route back to node.

In any case, 'destination unreachable' is not a reliable mechanism.
The fact that the packet will be dropped instead of potentially
misdelivered is the important point.

> 	ISP's can however help by counting and reporting ULA

Certainly, that can have diagnostic value.

    Brian