[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

"A6 was a concrete solution, with plusses and minuses, and is dead now."



"A6 was a concrete solution, with plusses and minuses, and is dead now."

A6 can not be dead, it is the heart and soul of IPv6. Without A6, how can there be an IPv6 ?

AAAA is for use with IPv4++. New versions of Windows produce IPv4 packets when sent 2002: model year addresses.

128-bit DNS AAAA Record Flag Day Formats
2002:[IPv4]:[SDLL.OFFF.FFFF.TTTT]:[64-bit IPv8 or IPv16 Persistent Address]
[YMDD]:[IPv4]:[SDLL.OFFF.FFFF.TTTT]:[64-bit IPv8 or IPv16 Persistent Address]
1-bit to set the Reserved ("Spare") bit in Fragment Offset [S]
1-bit to set the Don't Fragment (DF) bit [D]
2-bits to select 1 of 4 common TTL values (255, 128, 32, 8) [LL]
1-bit for Options Control [O]
7-bits to set the Identification Field(dst) [FFFFFFF]
4-bits to set the TOS(dst) Field [TTTT]
Default SDLL.OFFF.FFFF.TTTT = 0000.0000.0000.0000
FFF.FFFF.TTTT = GGG.SSSS.SSSS

Jim Fleming
2002:[IPv4]:000X:03DB:...IPv8 is closer than you think...IPv16 is even closer...
http://www.netfilter.org/
http://www.analogx.com/contents/dnsdig.htm
http://ipv8.dyndns.tv
http://ipv8.yi.org
http://ipv8.dyns.cx
http://ipv8.no-ip.com
http://ipv8.no-ip.org
http://ipv8.no-ip.biz
http://ipv8.no-ip.info
http://ipv8.myip.us
http://ipv8.dyn.ee
http://ipv8.community.net.au
http://ipv8.ods.org

----- Original Message ----- 
From: "Paul Vixie" <paul@vix.com>
To: <v6ops@ops.ietf.org>
Sent: Wednesday, September 18, 2002 4:21 PM
Subject: Re: renumbering 


> > | however, at size 10**4 and above, renumbering of this kind will be 
> > | expensive.
> > 
> > The actual renumbering need not be expensive.  At the minute it would be,
> > but more tools/protocols can be developed to make the kind of renumbering
> > we're talking about more or less invisible as far as the site is
> > concerned (and yes, A6 would certainly have helped).
> 
> A6 was a concrete solution, with plusses and minuses, and is dead now.
> 
> Alternatives which would also make renumbering less expensive are just
> vaporware at the moment, and since I can't evaluate them I can't accept
> your assertion that actual renumbering need not be expensive.
> 
> > | and at size 10**5 and above, it will be constant/overlapping.
> > 
> > Huh?  What does the size of the net have to do with the frequency of
> > renumbering - if anything, smaller nets are the ones that tend to shift
> > around more frequently (they don't have the clout to get good deals from
> > providers initially, nor do they usually engage in longer term agreements
> > to achieve that - bigger places do).
> 
> Larger networks are less mobile only when renumbering makes it so.  If you
> take away the renumbering penality (for example, if you use NAT) then I'd
> expect any network who attends a transit exchange such as PAIX or Equinix
> to change their provider at least once a month during fee wars.
> 
> > | ..., that's a big reason why folks will ask "why not just use NAT?"
> > 
> > And the answer will be, that NAT achieves nothing, but does limit
> > applications, some things just don't work.   And once we get into an
> > environment where the default isn't "everyone uses NAT", more of the
> > kinds of applications that just don't work with NAT are likely to appear
> > (there will be no reason for them not to).
> 
> What odds are you giving and how much are you putting up?
> 
> Please don't misunderstand my intent here.  I'm not using NAT and ISC is 99%
> done rolling out IPv6 internally and I'm not trying to get anybody to feel
> bad or act different concerning renumbering technologies, A6 or otherwise.
> 
> However, at the moment my take on all this is that folks are likely to use
> more NAT rather than less.  Any application author who wants to make their
> work NAT-unfriendly can't be -- and shouldn't be -- stopped.  But as far as
> the core protocols go, I think we should do a better job avoiding moralism
> tham IPsec did.  ("L4 routing/switching/firewalling is evil, so let's cover
> the port numbers under the encryption envelope.")
>