Subject: RE: Local addresses and security? (was: SL deprecation draft)

From: "Christian Huitema" <[email-masked]>
Date: Sun, 23 Nov 2003 16:06:15 -0800

> > You can get verifiably unique addresses if you go through the
> > registration procedure. So, if you follow the good housekeeping
rules,
> > you should never encounter the bug you mention.
> 
> Though I'd also ask: "Claim portions of WHAT network?"  I'm talking
about
> *local* addresses, which by definition and design are not valid for
use on
> the global internet (and those nice little filters we want to mandate
help
> discourage people from trying).
> 
> Sure, you can claim large tracts of local space, for all the good that
> does
> you ("I declare that this 60% of this sandbox is now MINE."), but the
> approximately unique property is primarily designed to make it much
eaiser
> to merge local networks.  So you only need to be piecewise unique with
> people with whom you might want to create a local VPN.

Andrew, the draft has provision for both "registered unique local
addresses" and "probably unique local addresses". The registered unique
addresses are not valid on the Internet, but they definitely will not
collide with other addresses.

-- Christian Huitema

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "EricLKlein" <[email-masked]>
Date: Mon, 24 Nov 2003 08:37:39 +0200

> collide with other addresses.

I am still have 2 concerns with these concepts:
1. People do not want to register their secure internal network nodes (bank
central computes etc) so the "registered unique local addreses" may not meet
their needs. They do not want to have even theoritically reachable addresses
on a Cash machine or other secure node that needs to be connected as part of
the private network.

2. For the "approxiamtely" or "probably" unique local addresses I am
concerned that these addresses will eventually be assigned as part of the
registered addresses and can then be in conflict with "legitimate" nodes.

So between the 2, I do not see a solution that will work better than a
RFC1918 type of address space. The more I hear about these options the more
I want to bring back site local addresses.

Eric

---

From: Mark Smith <[email-masked]>
Date: Mon, 24 Nov 2003 18:02:48 +1030

On Mon, 24 Nov 2003 08:37:39 +0200

> registered addresses and can then be in conflict with "legitimate" nodes.

Probably not going to happen in the next 200 years or more, and more likely it will never happen. By the time that becomes a possibility, IPv7 or IPv8 will be ready, with, based on the IPv4 32 bit -> Ipv6 128 bit trend, 512 bit addresses ... of course, every bit added doubles the size of the address space.

I'm sure somebody can provide a more accurate figure, but with all the currently planned IPv6 address space allocations, there is still in the order of 3/4 unallocated (not unassigned), for any purpose. That 3/4 would have to be used up before your concern becomes a possiblity.

> I want to bring back site local addresses.

I suggest you have a read or review the following two IETF documents :

"RFC 2993 - Architectural Implications of NAT"

http://www.faqs.org/rfcs/rfc2993.html

Site Locals opens the NAT can of worms in IPv6. NAT is worth avoiding.

Review the SL deprecation draft. If nothing else, Section 2 - "Adverse effects of site local addresses" is worth reviewing again to understand why duplicated address spaces cause problems.

http://www.ietf.org/internet-drafts/draft-ietf-ipv6-deprecate-site-local-02.txt

The H/H addresses aren't perfect, but they do seem to be the best solution that meets the largest number of functionality goals, without resorting to Provider Independent addressing. PI would be perfect, except that it is likely to cause the default free routers to melt down in the longer term. As in much of life, it is a trade off.

Regards,
Mark.

---

From: Leif Johansson <[email-masked]>
Date: Mon, 24 Nov 2003 08:45:40 +0100

>
 > Probably not going to happen in the next 200 years or more, and more 
likely it will never happen. By the time that becomes a possibility, 
IPv7 or IPv8 will be ready, with, based on the IPv4 32 bit -> Ipv6 128 
bit trend, 512 bit addresses ... of course, every bit added doubles the 
size of the address space.

Doubtful. The versions you cite have already been co-opted by a
well-known troll. But seriously; thank you for your list of
references. I have been having deja-vue all over again these
last few days :-(

	MVH leifj

---

From: "EricLKlein" <[email-masked]>
Date: Mon, 24 Nov 2003 10:58:43 +0200

Tim Chown wrote
>
> So they can use addresses from the probabilistically unique range under
> the space fd00::/8.  There is, in terms of raw usage, no difference
between
> using fd00::/8 or fec0::/10.   External networks would still have to route
> the prefixes back to you for you to be reachable, which is just as
hard/easy
> under either system.
Then why not jsut reuse the FEC8:: through FECB:: addresses that were
originally the site locals, and are now going to have to be left unallocated
for a while? It seems a little wasteful to allocate another range when we
have one that is "effectively lost".

> Well, addresses under fd00::/8 and fd00::/8 can be used locally just like
> site-local addresses, only they have the nice property of significantly
> reduced (probabilisticly unique) or complete removal of (registered
unique)
> ambiguity, so I don't see where your concern is?
>
> It is not unlikely that people will be lazy and just use fd00::/48 for
sites,
> and thus add back in great ambiguity to the probabilisticly unique address
> space.

First you ask a question, and then answer it. I am concerned that the many
network "experts" out there that are trained in a 2 week certification
course will take what is taught to them as an example and will make it
gospel, and thus use the exact same addresses in multiple networks in close
geographic proximity, and thus on the same Carrier edge router. Consider
what happens when a carrier implements IPv6 in a city, and suddenly there
are 10 companies connected by inexperienced network "experts" (and they have
the certificate to prove it) that all follow the exact same course
"template". Now this one carrier edge router is connected to 10 incorrectly
configured routers all using the exact same "probabilistically unique
address". this is where the original need for RFC1918 came from.

I still prefer to have this more defined so that the providers can block a
range as part of their access lists or filters.
Eric

---

From: Ignatios Souvatzis <[email-masked]>
Date: Mon, 24 Nov 2003 11:16:51 +0100

On Mon, Nov 24, 2003 at 06:02:48PM +1030, Mark Smith wrote:
 
> IPv7

already proposed at least twice: TP/IX (RFC 1475) or CATNIP (RFC 1707)?

Regards,
	-is

---

From: Brian Haberman <[email-masked]>
Date: Mon, 24 Nov 2003 06:10:57 -0500

Eric,

> registered addresses and can then be in conflict with "legitimate" nodes.

I'm curious, have you read draft-ietf-ipv6-unique-local-addr-01.txt?
The locally assigned prefixes come out of the FD00::/8 range and
the centrally assigned prefixes come out of the FC00::/8 range.  Can
you explain to me why you think they will collide at some point?

Regards,
Brian

---

From: "EricLKlein" <[email-masked]>
Date: Mon, 24 Nov 2003 10:03:44 +0200

Mark Smith wrote

> Probably not going to happen in the next 200 years or more, and more
likely it will never happen. By the time that becomes a possibility, IPv7 or
IPv8 will be ready, with, based on the IPv4 32 bit -> Ipv6 128 bit trend,
512 bit addresses ... of course, every bit added doubles the size of the
address space.
>
> I'm sure somebody can provide a more accurate figure, but with all the
currently planned IPv6 address space allocations, there is still in the
order of 3/4 unallocated (not unassigned), for any purpose. That 3/4 would
have to be used up before your concern becomes a possiblity.

I personally have not tried the algroythm for all possible cases, but I am a
firm believer in Murphy's Law, and i am sure that there will be more than 1
company using some block of addresses when you combine registeres,
"approximately unique", and just take what I want address spaces. This is
not from an academic or programming view but from 10 years in the field
connecting LANs into WANs. People want what they know not what works in the
lab.

> Site Locals opens the NAT can of worms in IPv6. NAT is worth avoiding.
This may be the case, but I keep seeing proposed standards about how to
implement NAT in IPv6.  So it seems to me that NAT is not dead. For examples
see:
http://www.ietf.org/internet-drafts/draft-ietf-nsis-nslp-natfw-00.txt
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rtsp-nat-01.txt
http://www.ietf.org/internet-drafts/draft-takeda-symmetric-nat-traversal-00.
txt
http://www.ietf.org/internet-drafts/draft-ford-midcom-p2p-01.txt
http://www.ietf.org/internet-drafts/draft-ietf-nat-natmib-07.txt
http://www.ietf.org/internet-drafts/draft-huitema-v6ops-teredo-00.txt
http://www.ietf.org/internet-drafts/draft-ietf-ipsec-nat-t-ike-07.txt
http://www.ietf.org/internet-drafts/draft-ietf-mobileip-nat-traversal-07.txt

The list of IPv6 plus NAT is over 140 documents long, with many of them
being proposed in the last 5 days. The look up list I ran is:
http://search.ietf.org/cgi-bin/htsearch?config=htdig&restrict=http%3A%2F%2Fw
ww.ietf.org%2Finternet-drafts%2F&exclude=&matchesperpage=50&method=and&forma
t=builtin-long&sort=time&words=%2Bnat+%2BIPv6

I will look over the document that you recommend, but please understand that
while we in this WG are depreciating site locals, other people seem to be
working hard on NAT and other uses for the site locals that already exist in
the existing RFC.

> As in much of life, it is a trade off.

I agree, but we need to make sure that what we trade off still works in the
end.

---

From: Mark Smith <[email-masked]>
Date: Tue, 25 Nov 2003 00:08:25 +1030

On Mon, 24 Nov 2003 14:54:41 +0200
"EricLKlein" <[email-masked]> wrote:

> 
> Can you explain why are we allocating another range for locally assigned
> prefixes, rather than reusing the FEC8:;  FEC9::  spaces that were used this
> way and are now going to stay unallocated? Why tie up a second range?

Because code may exist that assumes the probably soon-to-be-former SL functionality.

Regards,
Mark.

---

From: Mark Smith <[email-masked]>
Date: Tue, 25 Nov 2003 00:06:06 +1030

On Mon, 24 Nov 2003 15:00:46 +0200
"EricLKlein" <[email-masked]> wrote:

> Tim Chown wrote:
> 
> > On Mon, Nov 24, 2003 at 10:03:44AM +0200, EricLKlein wrote:
> > >
> 
> This may be true, but no one is proposing green cow become an IETF standard.
> The list I provided is recently proposed IETF drafts on when and how to use
> NAT with IPv6.
>

I recommend you read some of the drafts you are listing. The "toredo" draft for example.

> If there are this many new drafts coming out in November 2003, even with a
> WG decision to not do NAT IPv6 then there should be a big red flag that
> there is a disconnect between what this WG says and what others are doing.
> 

I would prefer to say it the other way ... if your evidence is actual, it shows the other groups are disconnected with this one.

Regards,
Mark.

---

From: "EricLKlein" <[email-masked]>
Date: Mon, 24 Nov 2003 14:54:41 +0200

> you explain to me why you think they will collide at some point?
To be honest, as stated in another e-mail, I have not read the
draft-ietf-ipv6-unique-local-addr-01.txt, I am catching up on drafts and
will read it soon.

Eric

---

From: "EricLKlein" <[email-masked]>
Date: Mon, 24 Nov 2003 15:00:46 +0200

> So I google for "green cow" and get a million hits... but there are very
> few green cows out there...
>
> People will use IPv6 with NAT, but then they may as well stick with
IPv4+NAT.

Eric

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 24 Nov 2003 15:50:05 +0100

EricLKlein wrote:
> their needs. 

There is no way to get a unique prefix without a central allocator (i.e. a
registry, whether it's human or a robot). That's the reason for using the
word "escrow" to describe the way the registry retains its information.

> They do not want to have even theoritically reachable addresses

The Hinden/Haberman addresses are not theoretically reachable. They are (like
RFC 1918 or FEC0::/10) theoretically unreachable. Their new characteristic
is unambiguity, which experience with RFC 1918 has shown is very necessary.

The usual warning about the difference between theory and practice applies
in all these cases, of course.

> registered addresses and can then be in conflict with "legitimate" nodes.

No. Please read the draft. This cannot happen.

> I want to bring back site local addresses.

The only real differences are that you get unambiguity, which is a MUST 
from RFC 1918 experience, and you lose the woolly concept of site scope,
which we don't know how to use.

   Brian

---

From: "EricLKlein" <[email-masked]>
Date: Mon, 24 Nov 2003 17:52:44 +0200

Mark Smith wrote
> I would prefer to say it the other way ... if your evidence is actual, it
shows the other groups are disconnected with this one.

I agree, but either way there is a disconnect.

---

From: Fred Templin <[email-masked]>
Date: Mon, 24 Nov 2003 09:34:20 -0800

Eric,

>draft-ietf-ipv6-unique-local-addr-01.txt, I am catching up on drafts and

I'm a bit perplexed that you seem to have time to engage in
the e-mail discussions but have not yet found the time to read
documents that already address many/most of the points you
are raising.

It would perhaps serve to get us all on the same page if you
could give some of the relevant documents a look.

Thanks - Fred
[email-masked]

---

From: Fred Templin <[email-masked]>
Date: Mon, 24 Nov 2003 09:43:41 -0800

Whoops! I sent this before seeing the similar note from
Christian. Not meaning to belabor the point or otherwise
come down too hard on you, Eric. You are certainly not
the only one involved in these discussions who could
benefit from a read of the documents.

Fred
[email-masked]