On Mon, 24 Nov 2003 10:33:41 +0200 "EricLKlein" <[EMAIL PROTECTED]> wrote:
> > 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. 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 > not from an academic or programming view but from 10 years in the field > 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. > > > > > > 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 > 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 : http://www.ietf.org/internet-drafts/draft-huitema-v6ops-teredo-00.txt 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 > > 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. > 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. > > 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. > 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. -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
