Dan, > Dan Lanciani wrote: > So your position is that I must do one of those two rather > than using site-local addresses on the one segment along > with the two globals? I believe that this restriction > renders site-locals useless for many applications. > I would be forced to opt for NAT.
You don't have NAT and you are not going to write yourself. Forget it. >> I don't see what your problem is with 1, because the >> smallest you can get is a /64 anyway, which is enough >> for more printers and workstations than you will ever have. > There seems to be a persistent notion that ISPs are going to > change their business models just because the IP header > version field increases by 2. I don't buy it. Show me proof. The IID is 64 bits, please read the addressing architecture draft. Same as a v4 ISP could not give you less than ONE IPv4 address, a v6 ISP can not give you less than ONE /64. > If you ban packets with global addresses from your > site-local subnet then the site-local machines > (obviously) can't talk to globally-connected machines > via their global addresses. In my example, this makes > #2 impossible. Sorry, I misread you. There is no such restriction. > There's no restriction on having site-locals and globals > on one subnet either, but we seem to be talking about > adopting one or more of these restrictions. That is called political compromise. However, I am glad you contributed your feelings, and I would stick to what I wrote in my original answer about this: If it's only me, ok to scrap it. If some other people do insist on having this feature, keep it. > I cannot support your position. This restricted version of > site-locals may have some marginal security benefit, but it > fails to deliver on the original promise of flexible scoping. > It will just cause confusion for administrators who will > think they can control their address allocations... until > they actually try to do it. Okay, I tried, no cigar. I actually think exactly as you do, so let's stick to site-locals as we both want them. No restriction other than what Bob Hinden mentioned yesterday. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
