Subject: Re: [arch-d] Mobility and multi-homing: Summary and going forward

From: Paul Vixie <[email-masked]>
Date: Sat, 12 Nov 2005 04:17:08 +0000

it seems that a goodly portion of the historical record on this has been lost,
or perhaps just not passed on by father to son.  here are some of the comments
i made when IPv6's original "rapid renumbering" requirement was thrown out as
a way to make it more (cough) rapidly deployable.

it gives me no pride or pleasure to have been right in my various predictions.
i'm only sending these again so that those of you who weren't involved in 1996
can have some context as you unearth all these supposedly-dead issues.  had we
stuck with A6/DNAME, we'd be ~done by now.  instead, we're ~starting ~over.

(4 msgs)

Subject: Re: FW: AAAA/A6
From: Paul A Vixie <[email-masked]>
To: [email-masked]
Date: Thu, 22 Mar 2001 05:58:39 -0800

A6 wasn't originated by the DNS community, it was a response to the IPv6
community's desire to push their rapid/continuous renumbering requirement
into DNS rather than having to invent new support protocols in IPv6 itself.

Therefore if the IPv6 community withdraws its rapid/continuous renumbering
requirement then the DNS community will absolutely withdraw its A6 proposal.
I do not consider this likely, and moreover, while I'm not a direct
participant in the IPv6 community, I think that rapid/continuous renumbering
is the only thing that makes IPv6 worth deploying.

> 	- name server with good backend database
> 		(in this case AAAA and A6 management costs are requal)

For any given network this may or may not be the case.  Sounds like for the
IIJLab network it is the case.  But I know of hundreds of networks for whom
it is NOT the case (starting with most of PAIX's customers.)  Good backend
databases, or even...

> 	- good perl script with AAAA (easy enough, deployable now)

...good perl scripts, are not universally applicable or scalable, and will
not lead to transit-provider fluidity.  Some of the stickiness of a network
to its transit provider has to do with the cost of renumbering.  And at the
moment, multihoming is hellishly expensive since it requires portable address
space which most networks don't have the resources to qualify for.

> 	i believe our network is already large enough, and i'm happy with AAAA.

in contrast, i believe that IPv6 is not worth its deployment cost, not even
in a testbed, unless we deploy (or test) the rapid/continuous renumbering
features.  if you don't believe me, find a member of the GPRS community and
ask *them*.  or anyone in the mobile data community.  or anyone whose network
touches PAIX or Equinix or similar for the majority purpose of selecting their
transit providers based on price and quality and without regard to renumbering
cost.

Subject: Re: AAAA/A6 thing
From: Paul Vixie <[email-masked]>
To: [email-masked]
Date: 28 Apr 2001 10:57:35 -0700

> Yes, there are a few A6 RR's out in the wild - but aside from demonstrating
> that the world hasn't ended because of that, those don't prove much,
> either way.

Nor will proof of that kind be available without a lot more operational
deployment.  

It sounds like you're not planning to wait for proof of that kind, but
rather, get in a room with some like minded others and simply decide
whether A6 is worth deploying or whether it really does suffer from all
the woes which have been attributed to it and if so whether they add up
to something fatal or not.

Which means IPv6's "quick renumbering" requirement is back on the table.
And since quick renumbering was used to sell the fast path IPv6 is on, I
assume that we can now listen to Tony Li's "too little, too soon" complaint
and just pull back from IPv6-as-specified and try to come up with something
that's going to solve more of the problems we DO and WILL have, and fewer
of the problems we MIGHT or COULD have?

No?  You mean that stuff isn't back on the table, and we're going ahead with
IPv6 regardless of whether or not it has quick renumbering capabilities?  If
so, I will accuse the various directorates of "bait and switch" tactics used
to ram their limited vision through various debates with no actual intent to
follow through on any of their "campaign promises."

Which would make this whole thing a lot like the RSA/DSA problem DNSSEC has.

Are we still considering rearranging the IPv6 packet format to put destination
address first?  After all if the whole thing's still so experimental that we
don't know what features it has or how we will deliver them, let's see the
WHOLE laundry list.  (I don't think IPv6 could stand that kind of scrutiny,
but then, neither could IPv4 if it were proposed today.)

Hint to whoever is in charge: the time to debate A6's merits at this level
was: before it got put on the standards track, before a lot of code got
written, and before a lot of operational deployment was put into various
long and expensive pipelines.
-- 
Paul Vixie <[email-masked]>
President, PAIX.Net Inc. (MFNX.O)

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary
From: Paul A Vixie <[email-masked]>
To: Jun-ichiro itojun Hagino <[email-masked]>
Cc: Alexis Yushin <[email-masked]>, James Aldridge <[email-masked]>, Jim Bound <[email-masked]>, Matt Crawford <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Date: Tue, 07 Aug 2001 10:48:17 -0700

> 	i have a major concern with AAAA synthesis - which is, it is unclear
> 	as to who needs to AAAA synthesis.  the concern is mentioned
> 	in my draft.
> 
> 	- you can't guarantee every first-hop DNS server to do AAAA synthesis.
> 	- if anyone does not, AAAA queries go into non-first-hop DNS servers
> 	  by recurse (imagine when pre-BIND9/non-BIND name server is used
> 	  as the first-hop name server).
> 
> 	therefore, AAAA synthesis basically asks everyone to run AAAA and A6
> 	in parallel, which raises a lot of concerns (query delays if you query
> 	both, database maintenance cost if you maintain both in zone, no-sign
> 	if you synthesize, and a lot of others).

i would much rather deal with those problems, since they are solvable, then
to deal with non-renumberable 128 bit addresses, since they simply lead to
NAT.

i cannot emphasize strongly enough that vast numbers of transit-consumers
who lack the various powers needed to own portable address space will NOT
deploy globally addressable IPv6 space if it simply means that they will
become even more captive of their ipv6-transit providers than they are of
their ipv4-transit providers today.

the gprs and other mobile data providers are mostly going to be able to
own portable address space so they don't care about this issue.

but for "the enterprise" this is a real problem.

if ipv6 is no easier to renumber than ipv4, then we're going to see large
scale NAT.  much larger scale NAT than we see today.

being a captive customer of some transit provider when you only have an
ipv4 /24 or even a /20 that you have to renumber if you change providers
has difficulty N.  being a captive customer of some transit provider when
you have an ipv6 /64 to renumber if you change providers has difficulty
N*(2^44).  if NAT is used then the difficulty in either case is a constant,
and for that matter, it's the same constant.

so, "let's standardize both and let the market decide."

but right now i'm hearing three camps trying to kill A6:

	implementors who consider bitstring, A6, and DNAME "too hard to do"

	transit providers who like the idea of captive ipv6 /64 customers

	transit customers who have enough power to own their own ipv6 blocks

who in this mix is representing the interests of the average MIS manager?
(and who do you think is going to drive the ipv6 economy, anyhow?)

this debate borders on "simply unbelievable."

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

Subject: Re: renumbering
From: Paul Vixie <[email-masked]>
To: [email-masked]
Date: Tue, 17 Sep 2002 20:45:10 +0000

> 	i have renumbered my home (/48) more than a couple of times without
> 	any problem.  yes, it may not extend naturally to enterprise network 
> 	where # of nodes are 10^4, but anyway,
> 	- IPv6 address autoconfiguration
> 	- multiple IPv6 address per interface
> 	- source/destination address selection
> 	makes renumbering so much easier than IPv4 case.  you just need to be
> 	careful about DNS TTL and RA address/prefix lifetime.

there's no question that it's easier than the ipv4 case.  congrats are
in order on that point.

however, at size 10**4 and above, renumbering of this kind will be 
expensive.  and at size 10**5 and above, it will be constant/overlapping.

my point was, that's a big reason why folks will ask "why not just use NAT?"

now i'm thinking, please don't make NAT any harder than it already is.
_______________________________________________
Architecture-discuss mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/architecture-discuss

---

From: Thomas Narten <[email-masked]>
Date: Tue, 15 Nov 2005 12:08:04 -0500

Hi Paul.

> it seems that a goodly portion of the historical record on this has
> been lost, or perhaps just not passed on by father to son.  here are
> some of the comments i made when IPv6's original "rapid renumbering"
> requirement was thrown out as a way to make it more (cough) rapidly
> deployable.

You've made this assertion before. But if we're going to talk about
the historical record, can you remind me of where the "rapid
renumbering" requirement actually comes from, and who actually made
it? RFC 1752 (The Recommendation for the IP Next Generation Protocol)
doesn't seem to list it as a requirement.

Does IPv6 make renumbering easier? Almost certainly. Does it make it
trivial or painless? Certainly not.  How much easier is renumbering in
IPv6 compared to IPv4? Hard to say, since we have little
experience. Moreover, the pain of renumbering certainly varies
depending on what it is you are renumbering. I'd say that renumbering
end hosts is easier in IPv6 than IPv4. But just how much is a tad
subjective...

Is it easier to renumber the network infrastructure in IPv6, e.g.,
routers?  This is less clear. I'd again say yes, because being able to
run both an old and new prefix in parallel while transitioning works
better in IPv6 than IPv4. (Having IP stacks support multiple addresses
is something that IPv6 certainly does better archtecturally -- it's
designed in - compared with IPv4, where its support is ad-hoc and not
uniform.) But certainly it's not free or painless, and there are few
automated tools for renumbering an IPv6 infrastructure, at least not
yet.

> it gives me no pride or pleasure to have been right in my various
> predictions.  i'm only sending these again so that those of you who
> weren't involved in 1996 can have some context as you unearth all
> these supposedly-dead issues.  had we stuck with A6/DNAME, we'd be
> ~done by now.  instead, we're ~starting ~over.

If you are suggesting that all that is needed to make renumbering easy
in IPv6 as something like A6/DNAME, I disagree. While having A6/DNAME
might help some, it is by no means sufficient. The hard part of
renumbering is not the DNS, but actually renumbering the
infrastructure and getting everyone to stop using the old addresses in
favor of the new ones. I don't know of any way to do that "rapidly".

Sure, getting applications to switch to new addresses is something the
DNS can help with, but unless you want to break caching (by using very
short RR TTLs) the idea of doing a "rapid update" in DNS is a
non-starter. And once you've accepted that renumbering is not an
instantaneous event, but involves an overlap/transition period where
both the old and new addresses work for a period of days or weeks, the
need for A6 becomes much less apparent. IIRC, one of the original
arguments for why A6 wasn't really that compelling was that at least
some of its benefits could be achieved via better DNS config file
tools. For example, allowing AAAA RRs to be specified as being
composed of components (rather than a complete address), one of which
was the network prefix would simplify the task of updating config
files, in that updating the DNS when renumbering would consist of just
updating a single prefix as opposed to updating every AAAA entry via
global substitute.

Thomas