who gets a /32 [Re: IPV6 renumbering painless?]

Mailman List Mirror (Read Only)
1

(catching up)

(you missed some stuff.)

> (let me put it this way: A6/DNAME was shot down because of
> complexity, and it was simpler than this.)

I am not convinced A6/DNAME would have solved all problems, not even
all of the ones you pointed out.

the property of a6/dname that wasn't widely understood was its intrinsic
multihoming support. the idea was that you could go from N upstreams to
N+1 (or N-1) merely by adding/deleting DNAME RRs. so if you wanted to
switch from ISP1 to ISP2 you'd start by adding a connection to ISP2, then
add a DNAME for ISP2, then delete the DNAME for ISP1, then disconnect ISP1.

the DNAME was expected to be inside your own zone. presto, no lock-in.
my theory at the time, bitter and twisted i admit, was that we had too
many ISP employees in positions of power inside IETF, and that A6/DNAME
was seen as shifting too much power to the endsystems. i've since learned
that it was just another case of FID (fear, ignorance, and doubt).

naturally this presumed that you could add and delete ipv6 supernets from
a LAN, which appeared to be the case at that time, though now with dhcp6
and static addressing making a comeback that's no longer clear. in any
case there was a need for a TCP option for endpoint-renumber, which was
killed in a committee somewhere (i don't know which one, or where or when.)

given that ipv6 is now somewhat deployed without rapid renumbering, and
that rapid renumbering could have required logic in "both endpoints" of
every flow, but that there are now a lot of "other endpoints" without any
such logic, it seems to me that MULTI6's only option is to make NAT work,
even if you call it "site local addressing" or even "ULA's". (show me.)

2

[...]

Isn't about the same achievable with about two or three lines of scripting (or a new zone parsing option for bind :wink: with a lot less protocol complexity?

As you note, A6/DNAME wasn't a panacea. A lot additional stuff is needed to achieve the goal. It seems to me that actually the A6/DNAME part is a relatively simple one to achieve using current mechanisms.

3

Except that A6/DNAME also supported your upstream being able to initiate
prefix renumbering without having to involve the end customer...

As I understand it:

foo.blah.org. IN A6 MYISP1 ::4321:53ef
MYSIP1 IN DNAME 10 prefix1.isp1.net. ::dead:beef::

Then, in ISP1's isp1.net zone file

prefix1 IN DNAME 100 feed:beef::

This way, if ISP1 needed to renumber for some reason (turning in old /32 in
trade for /30, for example), they could go through the following steps:

prefix1 IN DNAME 200 feed:beef::
prefix1 IN DNAME 100 2314:5124::

Wait a few days for everyone to catch on to the new DNAME, then,

prefix1 IN DNAME 100 2314:5124::

Voila, painless ISP renumber without substantial end-user headache.

Sure, there are other issues (like bone-headed ACLs that accept/deny host
based on 128 bit address), but, this at least solved part of that problem.

Owen

4

> (catching up)

(you missed some stuff.)

eh, so must I have, atleast about multi-homing :slight_smile: I'll ask below.
(and yes, I'm still behind on the ipv6 reading I was supposed to do)

>
> > (let me put it this way: A6/DNAME was shot down because of
> > complexity, and it was simpler than this.)
>
> I am not convinced A6/DNAME would have solved all problems, not even
> all of the ones you pointed out.

the property of a6/dname that wasn't widely understood was its intrinsic
multihoming support. the idea was that you could go from N upstreams to
N+1 (or N-1) merely by adding/deleting DNAME RRs. so if you wanted to
switch from ISP1 to ISP2 you'd start by adding a connection to ISP2, then
add a DNAME for ISP2, then delete the DNAME for ISP1, then disconnect ISP1.

This makes some sense, however, how does the client system know which
address it should use? what lets the client know that the path from
client->server-address-ATT is better/worse/same as the path from
client->server-address-MFN or client->server-address-uu ? I would think
that the 'best' solution for all parties would be 'one' address for an end
system, or one path to the end system.

There are all sorts of reasons, from a client side, why ipv6 seems like a
huge mess, this is but one of them. It seems to me that other things like
outage detection toward the provider specific addresses (uu is down and
att is up, too bad I tried to get to the uu address) might also be a
problem.

From the server side things also seem extra-messy in v6:

1) forcing N DNS updates for each system address change (uu-forward,
mfn-forward, att-forward... and reverses if you care about that as well)
2) 'extra' server resources to serve extra zones with the same
information.
3) forcing urpf-like routing of traffic: uu out uu, att out att and mfn
out mfn off diverse routers upstream from the local LAN.

The world has been pushed toward multihoming of critical resources
(critical at multiple levels) over the last 10 years, forcing extra
complexity into v6 such that multihoming is now 'very difficult' (maybe
not for Paul or Mr. Rosen, but for many folks still) will delay the
rollout of v6 and it's acceptance.

Perhaps this is just 'normal' technology acceptance process, and perhaps
I'm missing a great many things in 'the v6-way', but if the multihoming
can't be worked out in a sane manner I can't see rollout and acceptance of
v6 coming any time soon.

such logic, it seems to me that MULTI6's only option is to make NAT work,
even if you call it "site local addressing" or even "ULA's". (show me.)

there are, and will be in the future, folks that WANT NAT, regardless of
the perceived 'badness' of it...

-Chris

5

[...]

Sure. But draft-ietf-v6ops-renumbering-procedure-03.txt says it IMHO well:

6. Acknowledgments
[...]
    Some took it on themselves to convince the authors that the concept
    of network renumbering as a normal or frequent procedure is daft.
    Their comments, if they result in improved address management
    practices in networks, may be the best contribution this note has to
    offer.

The main thrust of A6/DNAME is adding hooks for handling so-called 'rapid renumbering' and 'not-user-initiated-renumbering' scenarios. That seems unfeasible and unreasonable.

Renumbering cannot be prevented. And we should take all the reasonable actions to make sure it's manageable, because otherwise we'll end up with PI/ULAs and NATs. But AFAICS, obtaining a level of 'manageability' should be sufficient. We don't necessarily want or need to solve the most tricky renumbering problems here (e.g., rapid renumbering, automatic renumbering or large sites without any actions from the administrators, etc.).

To paraphrase Randy from a couple of years ago: 'Ocean: do not drain.'

6

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

  Paul,

(catching up)

(you missed some stuff.)

Yes, I have had lot's of fun reading through almost a week of Nanog...

the property of a6/dname that wasn't widely understood was its
intrinsic
multihoming support. the idea was that you could go from N upstreams
to
N+1 (or N-1) merely by adding/deleting DNAME RRs. so if you wanted to
switch from ISP1 to ISP2 you'd start by adding a connection to ISP2,
then
add a DNAME for ISP2, then delete the DNAME for ISP1, then disconnect
ISP1.

Somehow I must be confused. AFAIK DANME/A6 is/would be/could have been
of great help with the name to number mapping when renumbering. But the
main problem is the actual renumbering of the HOSTs. And I fail to see
how A6/DNAME would help. As a matter of fact the problems that was
brought to multi6 are a lot more than what you have listed A6/DNAME to
address. See RFC3582 and draft-lear-multi6-things-to-think-about-03.txt
for an overview.

given that ipv6 is now somewhat deployed without rapid renumbering, and
that rapid renumbering could have required logic in "both endpoints" of
every flow, but that there are now a lot of "other endpoints" without
any
such logic, it seems to me that MULTI6's only option is to make NAT
work,
even if you call it "site local addressing" or even "ULA's". (show
me.)

ULAs are not a product of multi6.

- - kurtis -

7

6. Acknowledgments
[...]
    Some took it on themselves to convince the authors that the concept
    of network renumbering as a normal or frequent procedure is daft.

[Note: check spell error - "draft" not "daft"]

    Their comments, if they result in improved address management
    practices in networks, may be the best contribution this note has to
    offer.

<sarcasm>

Oh? Is that "Acknolidgement" the only contribution IETF has to offer in
regards to renumbering? How pathetic!

To paraphrase Randy from a couple of years ago: 'Ocean: do not drain.'

Is that the same as "Ocean: do not cross"? I guess we're lucky Columbus
did not have same attitude to life as Randy...

</sarcasm>

8

the property of a6/dname that wasn't widely understood was its intrinsic
multihoming support. the idea was that you could go from N upstreams to
N+1 (or N-1) merely by adding/deleting DNAME RRs. so if you wanted to
switch from ISP1 to ISP2 you'd start by adding a connection to ISP2, then
add a DNAME for ISP2, then delete the DNAME for ISP1, then disconnect
ISP1.

This makes some sense, however, how does the client system know which
address it should use? what lets the client know that the path from
client->server-address-ATT is better/worse/same as the path from
client->server-address-MFN or client->server-address-uu ? I would think
that the 'best' solution for all parties would be 'one' address for an end
system, or one path to the end system.

Because when it matters, the administrator of the zone has the option of
removing the DNAME records for the provider that is sucking at the moment.
Not a panacea, but, at least help.

Single address may or may not be the best solution. One path to end system
is definitely NOT the right answer for everyone. More paths is less failure.

Perhaps this is just 'normal' technology acceptance process, and perhaps
I'm missing a great many things in 'the v6-way', but if the multihoming
can't be worked out in a sane manner I can't see rollout and acceptance of
v6 coming any time soon.

Apparently, you are, because, the whole DNAME/A6 thing was deprecated and
we were lamenting that it's existence would have made this somewhat simpler
to administer.

there are, and will be in the future, folks that WANT NAT, regardless of
the perceived 'badness' of it...

Why? You still have yet to justify this position.

Owen

9

I suspect that it is now time to agree to disagree.

I have said before and will say again:

  1. IPv4 is fundamentally flawed in that we are using a single
    resource as both an end-point identifier and a routing
    identifier. The phone companies figured out that these
    must be separate years ago.

  2. IPv6 took some steps to solve this by making this division
    somewhat artificially through the use of A6/DNAME, but,
    later backed off from this practice.

  3. IPv6 then completely failed to address issue 1 in any other
    way, and, so, we have, as near as I can tell, essentially
    come full circle to TUBA which we initially rejected largely
    because of issues like number 1 above.

To further paraphrase Randy: 'Swamp: do not drink.'

Owen

10

No, I think "daft" is the word intended in this case. It is a synonym
for "incompetent" or "stupid".

I don't happen to agree with it, but, I think that is what was intended.

Owen

11

Paul Vixie wrote:

(catching up)

(you missed some stuff.)

(let me put it this way: A6/DNAME was shot down because of
complexity, and it was simpler than this.)

I am not convinced A6/DNAME would have solved all problems, not even
all of the ones you pointed out.

the property of a6/dname that wasn't widely understood was its intrinsic
multihoming support. the idea was that you could go from N upstreams to
N+1 (or N-1) merely by adding/deleting DNAME RRs. so if you wanted to
switch from ISP1 to ISP2 you'd start by adding a connection to ISP2, then
add a DNAME for ISP2, then delete the DNAME for ISP1, then disconnect ISP1.

the DNAME was expected to be inside your own zone. presto, no lock-in.
my theory at the time, bitter and twisted i admit, was that we had too
many ISP employees in positions of power inside IETF, and that A6/DNAME
was seen as shifting too much power to the endsystems. i've since learned
that it was just another case of FID (fear, ignorance, and doubt).

naturally this presumed that you could add and delete ipv6 supernets from
a LAN, which appeared to be the case at that time, though now with dhcp6
and static addressing making a comeback that's no longer clear. in any
case there was a need for a TCP option for endpoint-renumber, which was
killed in a committee somewhere (i don't know which one, or where or when.)

As someone actively working on maintaining an TCP stack (FreeBSD 5.x and
6.x) I can tell you this is a blessing. Throwing more stuff into TCP is
only making matter worse and leads to lots of really buggy and non-working
implementations. TCP is pretty complex already and only a few people are
really up to it.

given that ipv6 is now somewhat deployed without rapid renumbering, and
that rapid renumbering could have required logic in "both endpoints" of
every flow, but that there are now a lot of "other endpoints" without any
such logic, it seems to me that MULTI6's only option is to make NAT work,
even if you call it "site local addressing" or even "ULA's". (show me.)

If you want that, then go for SCTP.

And please don't add any more layering violations. It makes implementors
life painful and kills any architectual cleaniess in operating systems.