> 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 PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
