Re: who gets a /32 [Re: IPV6 renumbering painless?]
(catching up)
(you missed some stuff.)
On 2004-11-22, at 18.52, Paul Vixie wrote:
(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.)
On Sun, 28 Nov 2004, Paul Vixie wrote:
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). [...]
Isn't about the same achievable with about two or three lines of scripting (or a new zone parsing option for bind ;) 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. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
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 --On Sunday, November 28, 2004 8:51 PM +0200 Pekka Savola <pekkas@netcore.fi> wrote:
On Sun, 28 Nov 2004, Paul Vixie wrote:
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). [...]
Isn't about the same achievable with about two or three lines of scripting (or a new zone parsing option for bind ;) 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.
-- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
-- If it wasn't crypto-signed, it probably didn't come from me.
On Sun, 28 Nov 2004, Owen DeLong wrote:
Except that A6/DNAME also supported your upstream being able to initiate prefix renumbering without having to involve the end customer... [...]
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.' -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
On Mon, 29 Nov 2004, Pekka Savola wrote:
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> -- William Leibzon Elan Networks william@elan.net
--On Sunday, November 28, 2004 11:35 PM -0800 "william(at)elan.net" <william@elan.net> wrote:
On Mon, 29 Nov 2004, Pekka Savola wrote:
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"]
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 -- If it wasn't crypto-signed, it probably didn't come from me.
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 --On Monday, November 29, 2004 8:53 AM +0200 Pekka Savola <pekkas@netcore.fi> wrote:
On Sun, 28 Nov 2004, Owen DeLong wrote:
Except that A6/DNAME also supported your upstream being able to initiate prefix renumbering without having to involve the end customer... [...]
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.'
-- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
-- If it wasn't crypto-signed, it probably didn't come from me.
On Sun, 28 Nov 2004, Paul Vixie wrote: > > > (catching up) > > (you missed some stuff.) eh, so must I have, atleast about multi-homing :) I'll ask below. (and yes, I'm still behind on the ipv6 reading I was supposed to do) > > > On 2004-11-22, at 18.52, Paul Vixie wrote: > > > > > (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
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 -- If it wasn't crypto-signed, it probably didn't come from me.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Paul, On 2004-11-28, at 17.47, Paul Vixie wrote:
(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 - -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBQarLg6arNKXTPFCVEQJUzgCfSgII26+xcvM8BQAb2P68UQjiR8gAnjfk xkw0hLIVRrz4RDJcxAzKksRC =z9eO -----END PGP SIGNATURE-----
Paul Vixie wrote:
(catching up) (you missed some stuff.) On 2004-11-22, at 18.52, Paul Vixie wrote:
(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. -- Andre
participants (7)
-
Andre Oppermann -
Christopher L. Morrow -
Kurt Erik Lindqvist -
Owen DeLong -
Paul Vixie -
Pekka Savola -
william(at)elan.net