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

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

> Mark Smith wrote
> > 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.

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

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

 Eric

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

---

From: Mark Smith <[email-masked]>
Date: Mon, 24 Nov 2003 19:36:37 +1030

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

> "approximately unique", and just take what I want address spaces.

Everybody can take the whole IPv6 address space if they want to, and use it how they like. They were free to do that with IPv4.

However, if those people choose to connect to the Internet, then, for the benefit of all users of the Internet, including themselves, they need to follow the policies of the Internet, which includes following / complying with the Internet's addressing policies.

 This is
> connecting LANs into WANs.

There are a number of people on this list who have the experience you have, including myself. I'm sure plenty of people on this list are very familar with daily operational issues. A lot of the very long and large SL discussions have occured because people have contributed their diverse experience and knowledge.

 People want what they know not what works in the
> lab.

When you are defining something new, like IPv6, nobody knows it at first, as it is being invented. IPv6 may be completely wrong. However, as long as everybody who has a vested interest in making it better than IPv4 has the opportunity to contribute, and they choose to, then hopefully it will be the best solution available.

People can't want something they know when it doesn't exist.

> t=builtin-long&sort=time&words=%2Bnat+%2BIPv6

A key word search on NAT doesn't show that the technology is worthwhile. A number of the drafts you highlight are actually specs on how to restore end-to-end i.e. bypass or work around the problems NAT causes. This one is an example :

I'm guessing these ones do as well :

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 
http://www.ietf.org/internet-drafts/draft-takeda-symmetric-nat-traversal-00.txt 

> working hard on NAT and other uses for the site locals that already exist in

Well, then, they should stop and review, at least if they think NAT is going to be an official part of IPv6. People on this list know the perils of NAT, and most consider the cost of endorsing it in IPv6 to be too high.

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

The only end there is is when the Earth gets burned up by the Sun, and that is a little while away. All solutions to anything are temporary, and only have to suit a current, near or relatively near (e.g. up to 100-200 years) need.

As long as IPv6 works in the near or relatively near interrim term, then it is good enough.

Regards,
Mark.