Re: existing (and questionable) application designs [was Re: US DoD and IPv6]
The referral problem he refers to is real, but I see it more as a consequence of the IETF being too rigid in its approach to address numbering. How would changing IETF's approach to address numbering help the referral problem? The basic question here is that we have two hosts that are to connect for a peer-peer protocol in which either endpoint can initiate or respond to a connection request. Clearly this is rather challenging if the boundaries between addressing schemes are arbitrary and becomes somewhat simpler in a uniform addressing model. But the real Internet is not like that. It is a network of networks and crossing the boundary between a private network and the interconnect space between the networks has consequences. One of those consequences is that addresses can change at the private/interconnect border. Another consequence is that crossing that boundary should have security consequences. In the real Internet, the boundary between a private network and the interconnect space is fuzzy and arbitrary, especially from a security point-of-view, and becoming moreso all the time. Opening up a port to receive connection requests has considerably greater security consequence than making the request. The requester is opening a communication channel with a single, specified entity, the responder is opening access to any host on the Internet. And far better mechanisms than opening up a port are feasible even within the classic Internet architecture. If the industry hasn't provided them, that's not the fault of the architecture. So opening a port is an event that should be mediated by access control at the host level and private/interconnect border at a minimum. In a default deny network there will be additional policy enforcement within the private network. There's a fundamental problem in that people have come to expect that somehow the network is responsible for keeping hosts secure from attack. Again, that's not the fault of the architecture. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: US DoD and IPv6
From: Keith Moore mo...@network-heretics.com
What doesn't work well is to have everyone decide for himself how to
change the architecture.
The reason we have/had a free-for-all on the architectural front is that the
IETF's choice for architectural direction (15 years ago) was non-viable (i.e.
wrong); it wasn't economically feasible (in terms of providing economic
benefits to early adopters, or otherwise having an economically viable
deployment plan), and it didn't offer any interesting/desirable new
capabilities (which was a big factor in the former).
With an 'approved direction' that didn't work, having people go off in their
own directions instead was an inevitable corollary.
Which is why I am urging the IETF to be _realistic_ now, and accept the world
as it actually is, and set direction from here on out based on that, and not
on what we wish would happen. Which means, for instance, that any design for
architecural change (e.g. introducing separation of location and identity) is
going to be somewhat ugly, because we don't have a clean sheet of paper to
work with. It also means accepting that we have multiple naming domains at
the end-end level, and will for the forseeable future; and trying to work out
an architectual direction for coping with that ('get rid of it' doesn't
count). Etc, etc, etc.
Noel
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: US DoD and IPv6
Let me say this more strongly. These two defects, it wasn't economically
feasible ... and it didn't offer any interesting/desirable new capabilities
were mild compared to an even bigger defect: There simply wasn't a technically
feasible plan on the table for co-existence and intercommunication of IPv4 and
IPv6 networks.
In addition to working our way through the IPv6 adoption and co-existence
process, I think it would be useful to do a little soul-searching and ask
ourselves if we're so smart, how come we couldn't design a next generation IP
protocol and work out a technically viable adoption and co-existence strategy.
The dual stack approach implicitly assumed everyone would have both an IPv6
and an IPv4 address. If everyone has both kinds of addresses, that implicitly
asserts there's no visible shortage of IPv4 addresses, which is contrary to
fundamental reason IPv6 is needed. Further, although some scenarios suggest
IPv4 usage will start to decline steeply once IPv6 transport, products and
services are widely available, the safer bet is that IPv4 networks will persist
for a fairly long time, say 20 to 50 years.
Steve
On Oct 8, 2010, at 9:36 AM, Noel Chiappa wrote:
From: Keith Moore mo...@network-heretics.com
What doesn't work well is to have everyone decide for himself how to
change the architecture.
The reason we have/had a free-for-all on the architectural front is that the
IETF's choice for architectural direction (15 years ago) was non-viable (i.e.
wrong); it wasn't economically feasible (in terms of providing economic
benefits to early adopters, or otherwise having an economically viable
deployment plan), and it didn't offer any interesting/desirable new
capabilities (which was a big factor in the former).
With an 'approved direction' that didn't work, having people go off in their
own directions instead was an inevitable corollary.
Which is why I am urging the IETF to be _realistic_ now, and accept the world
as it actually is, and set direction from here on out based on that, and not
on what we wish would happen. Which means, for instance, that any design for
architecural change (e.g. introducing separation of location and identity) is
going to be somewhat ugly, because we don't have a clean sheet of paper to
work with. It also means accepting that we have multiple naming domains at
the end-end level, and will for the forseeable future; and trying to work out
an architectual direction for coping with that ('get rid of it' doesn't
count). Etc, etc, etc.
Noel
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: US DoD and IPv6
Phillip Hallam-Baker hal...@gmail.com wrote: Since the one legacy protocol that has a dependency on IP address constancy is FTP, it would seem to me to be much easier to upgrade FTP to remove the dependency than to try to control the network. There are other protocols hiding out there. MATIP, RFC2351 (not from the IETF, obviously), allows either endpoint to send a session-open setting some paramaters for the session, and to confirm the session-open from the other side. So if both sides send session-open, they're both supposed to ignore the session opened by the endpoint with the lower-numbered IP. In practice, what this seems to mean is that sometimes when you set up new links, MATIP doesn't work, you get on the phone with the admins at the other side, and you agree which one of you will send the session open. Then you configure one endpoint never to send it. The RFC was published in 1998, though I don't know when they actually came up with the protocol. Its use is, I think, still increasing, as more airline industry links are set up over TCP/IP networks. I wouldn't have known about MATIP if I hadn't gotten a job related to airline industry networking, and I'm sure there are other naive protocols out there, designed by people or groups who were not that familiar with the way of the Internet and do protocols their own ways. [MATIP has a host of other problems that I won't mention :) ] -- Cos ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: US DoD and IPv6
any design for architecural change (e.g. introducing separation of location and identity) is going to be somewhat ugly, because we don't have a clean sheet of paper to work with. Location independent identifiers can be introduced at the transport or application layer, without having to change the network infrastructure. There is nothing to prevent researchers or application developers to design a transport that sits on top of IPv4/IPv6, or even on top of UDP, and manage location independent identifiers. This is the classic overlay play, at the end of which IPv6/IPv4 addresses, or address+port pairs, are redefined as mere lcators. Obviously, this only works for new applications, or new application releases. But if application developers really believe they will benefit from the split, they can do it. -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: US DoD and IPv6
--On Friday, October 08, 2010 09:47 -0400 Steve Crocker st...@shinkuro.com wrote: Let me say this more strongly. These two defects, it wasn't economically feasible ... and it didn't offer any interesting/desirable new capabilities were mild compared to an even bigger defect: There simply wasn't a technically feasible plan on the table for co-existence and intercommunication of IPv4 and IPv6 networks. In addition to working our way through the IPv6 adoption and co-existence process, I think it would be useful to do a little soul-searching and ask ourselves if we're so smart, how come we couldn't design a next generation IP protocol and work out a technically viable adoption and co-existence strategy. The dual stack approach implicitly assumed everyone would have both an IPv6 and an IPv4 address. If everyone has both kinds of addresses, that implicitly asserts there's no visible shortage of IPv4 addresses, which is contrary to fundamental reason IPv6 is needed. Further, although some scenarios suggest IPv4 usage will start to decline steeply once IPv6 transport, products and services are widely available, the safer bet is that IPv4 networks will persist for a fairly long time, say 20 to 50 years. Steve, While I agree with what you say (and most of what Noel says), hindsight is pretty easy. I even agree with your 20 to 50 year estimate although an optimist might draw some comfort from how quickly CLNP and CONP, TP0 and TP4 (and the rest of the OSI machinery), Vines and Netware, etc., disappeared once the network effects set in and the writing appeared on the wall. However, certainly Noel's position was part of the discussion 15-odd years ago. Certainly the positions that IPng must either be strictly forward compatible or that it should introduce enough new and valuable functionality to make people want to incur the pain were part of the discussion. Nonetheless, the IETF community selected what is now IPv6. What does this say about the IETF and how we make decisions? Does that need adjusting? Finally, and perhaps more important right now, while it is easy to observe that the 1995 (or 2000) predictions for IPv6 deployment rates have not come close to being satisfied and recriminations based on hindsight may be satisfying in some ways, the question is what to do going forward. There are communities out there who believe that we have managed to prove that datagram networks, with packet-level routing, are a failure at scale and that we should be going back to an essentially connection-oriented design at the network level. If they were to be right, then it may be that we are having entirely the wrong discussion and maybe that we are on the wrong road (sic) entirely. If not, then there are other focused discussions that would be helpful. The latter discussions that have almost started in this and related threads, but have (I believe) gotten drowned out by the noise, personal accusations about fault, and general finger-pointing. How would you propose moving forward? john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: US DoD and IPv6
And our friends at the ITU are standing by ready to help us too :-) Ole Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Cisco Systems Tel: +1 408-527-8972 Mobile: +1 415-370-4628 E-mail: o...@cisco.com URL: http://www.cisco.com/ipj On Fri, 8 Oct 2010, John C Klensin wrote: --On Friday, October 08, 2010 09:47 -0400 Steve Crocker st...@shinkuro.com wrote: Let me say this more strongly. These two defects, it wasn't economically feasible ... and it didn't offer any interesting/desirable new capabilities were mild compared to an even bigger defect: There simply wasn't a technically feasible plan on the table for co-existence and intercommunication of IPv4 and IPv6 networks. In addition to working our way through the IPv6 adoption and co-existence process, I think it would be useful to do a little soul-searching and ask ourselves if we're so smart, how come we couldn't design a next generation IP protocol and work out a technically viable adoption and co-existence strategy. The dual stack approach implicitly assumed everyone would have both an IPv6 and an IPv4 address. If everyone has both kinds of addresses, that implicitly asserts there's no visible shortage of IPv4 addresses, which is contrary to fundamental reason IPv6 is needed. Further, although some scenarios suggest IPv4 usage will start to decline steeply once IPv6 transport, products and services are widely available, the safer bet is that IPv4 networks will persist for a fairly long time, say 20 to 50 years. Steve, While I agree with what you say (and most of what Noel says), hindsight is pretty easy. I even agree with your 20 to 50 year estimate although an optimist might draw some comfort from how quickly CLNP and CONP, TP0 and TP4 (and the rest of the OSI machinery), Vines and Netware, etc., disappeared once the network effects set in and the writing appeared on the wall. However, certainly Noel's position was part of the discussion 15-odd years ago. Certainly the positions that IPng must either be strictly forward compatible or that it should introduce enough new and valuable functionality to make people want to incur the pain were part of the discussion. Nonetheless, the IETF community selected what is now IPv6. What does this say about the IETF and how we make decisions? Does that need adjusting? Finally, and perhaps more important right now, while it is easy to observe that the 1995 (or 2000) predictions for IPv6 deployment rates have not come close to being satisfied and recriminations based on hindsight may be satisfying in some ways, the question is what to do going forward. There are communities out there who believe that we have managed to prove that datagram networks, with packet-level routing, are a failure at scale and that we should be going back to an essentially connection-oriented design at the network level. If they were to be right, then it may be that we are having entirely the wrong discussion and maybe that we are on the wrong road (sic) entirely. If not, then there are other focused discussions that would be helpful. The latter discussions that have almost started in this and related threads, but have (I believe) gotten drowned out by the noise, personal accusations about fault, and general finger-pointing. How would you propose moving forward? john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: US DoD and IPv6
On Oct 8, 2010, at 9:36 AM, Noel Chiappa wrote: From: Keith Moore mo...@network-heretics.com What doesn't work well is to have everyone decide for himself how to change the architecture. The reason we have/had a free-for-all on the architectural front is that the IETF's choice for architectural direction (15 years ago) was non-viable (i.e. wrong); it wasn't economically feasible (in terms of providing economic benefits to early adopters, or otherwise having an economically viable deployment plan), and it didn't offer any interesting/desirable new capabilities (which was a big factor in the former). In hindsight, I suspect IETF could have made a better choice for IPv6. Or even accepting the basic IPv6 approach that we ended up with, slight changes to some of the details might have made a big difference. And it's worthwhile to try to learn lessons from that choice and the consequences. However, I don't see how it's constructive to say that the choice was wrong. There is today an increasingly widespread realization that the worldwide deployment of IPv6 is a better path forward than any of the likely alternatives. That doesn't mean it's the best possible path forward, of course. But as we're both painfully aware, having a better idea isn't sufficient. A necessary condition for success is to get widespread buyin to the idea. For better or worse, IPv6 is still the only semi-viable long-term strategy that has anything like widespread buyin. With an 'approved direction' that didn't work, having people go off in their own directions instead was an inevitable corollary. Except that neither middleboxes in general nor NATs in particular were a direct result of the decision to adopt IPv6. NATs were not originally driven by a shortage of IPv4 addresses. In the consumer market they were driven by what came to be a de facto standard of one IP address per customer, due partially to this assumption being widespread within IETF itself. In the enterprise network space they were initially driven by a misguided notion that having private addresses would produce better network security. In both cases the adoption of NATs was largely a consequence of IETF's failure to produce and adhere to a comprehensive plug-and-ping autoconfiguration architecture. The problem was that the 'approved direction' was wrong, it was that in many important spaces for both IPv4 and IPv6, there was no approved direction - only a hodgepodge of half-baked hacks that didn't fit together well. Which is why I am urging the IETF to be _realistic_ now, and accept the world as it actually is, and set direction from here on out based on that, and not on what we wish would happen. Sigh. Anytime someone makes an appeal to accept reality I wish a (small) brick would fall on his head. That's exactly the same kind of argument that was made in the late 1990s within IESG as to why IETF could not do anything to make NATs predictable to applications. But for what it's worth, I do share your assumption that we don't have the luxury of working from a clean sheet design. And I agree that at least in the near term it's going to be ugly. But I think the goal should be to facilitate a transition to a world that's less ugly, or at least more functional. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: US DoD and IPv6
On Fri Oct 8 17:10:56 2010, Keith Moore wrote: Except that neither middleboxes in general nor NATs in particular were a direct result of the decision to adopt IPv6. NATs were not originally driven by a shortage of IPv4 addresses. In the consumer market they were driven by what came to be a de facto standard of one IP address per customer, due partially to this assumption being widespread within IETF itself. In the enterprise network space they were initially driven by a misguided notion that having private addresses would produce better network security. In both cases the adoption of NATs was largely a consequence of IETF's failure to produce and adhere to a comprehensive plug-and-ping autoconfiguration architecture. Oh, I think there's rather more than that. Initially, NATs came about because enthusiasts found that it was prohibitively expensive to get a routed block down a modem - the ISPs treated you like a business customer, and charged accordingly. There's nothing the IETF could, or even should, have done to avoid this, and FWIW, the ISPs got terribly upset with you for using NATs at the time, and given the very few implementations (Linux IP Masq, for instance), some were able to detect and filter. As NATs moved from Linux IP Masq into the mainstream, though, ISPs simply took advantage of this - it meant that there was no configration distinction between a single user and a network - and that's a useful property. In hindsight, this would have been a good time for the IETF to step in and try to address the actual problem, but unfortunately consumer networking has never been a strong point of the IETF - I think largely because few of the stakeholders are average internet users for obvious reasons. As NATs drifted into the enterprise, there was a security angle, but there was also a renumbering angle that still hasn't gone away. This is, in no small part, because the only way to refer to an arbitary network is via the addressing - actual hosts are largely dealt with by a combination of DHCP and DNS. (As a random thought, if there was a CIDR DNS RR, I wonder if this may help?) There is occasional rumblings within the IETF to address this, but given NATs have to some extent removed the bulk of the pain, I'm not sure there's sufficient motivation to solve all the issues. So currently, a NAT provides: - A degree of de-facto firewalling for everyone. - An immunity to renumbering for enterprises. - Fully automated network routing for ISPs. If technologies could be introduced to tackle especially the last two, I think the advantages of NATs would vanish. Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: US DoD and IPv6
On Oct 8, 2010, at 12:31 PM, Dave Cridland wrote: On Fri Oct 8 17:10:56 2010, Keith Moore wrote: Except that neither middleboxes in general nor NATs in particular were a direct result of the decision to adopt IPv6. NATs were not originally driven by a shortage of IPv4 addresses. In the consumer market they were driven by what came to be a de facto standard of one IP address per customer, due partially to this assumption being widespread within IETF itself. In the enterprise network space they were initially driven by a misguided notion that having private addresses would produce better network security. In both cases the adoption of NATs was largely a consequence of IETF's failure to produce and adhere to a comprehensive plug-and-ping autoconfiguration architecture. Oh, I think there's rather more than that. Of course there is, but I was trying to be brief. Initially, NATs came about because enthusiasts found that it was prohibitively expensive to get a routed block down a modem - the ISPs treated you like a business customer, and charged accordingly. But part of that was because single-address-per-customer (or dialin session) was naturally a commodity service, while routing a block down a modem was something that required special-case handling at the ISP. And I think it's fair to say that that was the assumption in IETF also. I don't recall any efforts toward autoconfiguration of networks then, particularly not for those connected via point-to-point links. It's hard to not blame the ISPs for wanting to charge differently for one-address dialin vs. other accounts that required more customization, setup, and support on their part. As NATs drifted into the enterprise, there was a security angle, but there was also a renumbering angle that still hasn't gone away. This is, in no small part, because the only way to refer to an arbitary network is via the addressing - actual hosts are largely dealt with by a combination of DHCP and DNS. (As a random thought, if there was a CIDR DNS RR, I wonder if this may help?) Not sure what you mean by a CIDR DNS RR, but I hope it's nothing like A6 / DPTR was. There is occasional rumblings within the IETF to address this, but given NATs have to some extent removed the bulk of the pain, I'm not sure there's sufficient motivation to solve all the issues. And there's always considerable pressure on and within IETF to just embrace NAT for this. So currently, a NAT provides: - A degree of de-facto firewalling for everyone. - An immunity to renumbering for enterprises. - Fully automated network routing for ISPs. If technologies could be introduced to tackle especially the last two, I think the advantages of NATs would vanish. But the NATs are good mentality would still be widespread.Old timers hate to learn how to use new tools, even if the old tools are crap. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Internet Architecture (was US DoD and IPv6)
{'Borrowing' a new, more appropriate Subject: from a private reply...}
From: John C Klensin john-i...@jck.com
What does this say about the IETF and how we make decisions? Does that
need adjusting?
Perhaps, but even I shrink from tackling that particular windmill!
while ... recriminations based on hindsight may be satisfying in some
ways, the question is what to do going forward.
I couldn't agree with your latter point more.
There are communities out there who believe that we have managed to
prove that datagram networks, with packet-level routing, are a
failure at scale and that we should be going back to an essentially
connection-oriented design at the network level.
I (perhaps obviously) think that's a rash conclusion: the circa 1975 Internet
architecture was never intended to grow to this size, and that it has done so
at all (albeit via the use of a number of hacks, some merely kludgy, others
downright ugly) is a testament to how well the basic concept (of unreliable
packets, and minimal state in the network) works.
I do think that the architecture does require some work, though, and for a
number of reasons. For one, the real requirements have become more complex as
the network has grown, and a number that have arrived (e.g. provider
independence for users; the need for ISP's to be able to manage traffic
flows; etc) aren't really handled well (or at all) by the existing
architecture. For another, we need to bring some order to the cancerous chaos
that has resulted from piecemeal attempts to deal with the previous point.
Finally, it's a truism of system design that arrangements that work at one
order of scale don't at another, and as the network has grown beyond almost
our wildest expectations - and certainly larger than it was ever designed to
- I think we're seeing that too.
If not, then there are other focused discussions that would be helpful.
The latter discussions that have almost started in this and related
threads, but have (I believe) gotten drowned out by the noise, personal
accusations about fault, and general finger-pointing.
Well, sometimes one has to clear the air (or underbrush, if you will), and
get everyone's minds open, before one can make forward progress. But I agree,
'hah-hah, your end of the ship is sinking' rapidly becomes totally
unproductive.
How would you propose moving forward?
Well, IMO there are a number of things we need to do, which can be done all
in parallel.
The first is to be honest with ourselves, and with the people out there who
depend on us to set direction, about what's really likely to happen out in
the network; e.g. a very long period during which we are stuck with multiple
naming realms with various kinds of translators (NATxx) gluing them together.
This whole 'don't worry, everything will be fine' schtick has got to go -
we're now in what I call The Emperor's New Protocol land, where (almost)
everybody knows the theoretical plan isn't going to work, and major revisions
are needed, but nobody wants to come right out and say so formally.
We need to do that.
I think a group (set up by the IAB, who make these kind of pronouncements)
should sit down and draw up a _realistic_ picture of what the future over the
next couple of years (say, up to 5 years out - 5 only, because of a second
parallel effort, below) is likely to be, and get that out, so people have a
realistic appraisal of how things stand (and restore a little bit of the I*'s
credibilty, in the process).
That group (or perhaps a sister group) should produce a formal statement
covering the implications for IETF work of that present/future; i.e. about the
_existing_ architectural environment in which the protocols the IETF designs
have to operate, and thus have to be designed for. E.g. a formal IETF policy
statement 'all IETF protocols MUST work through NAT boxes'. Etc, etc.
The second is to set up a group (and again, this is the IAB's job) to try and
plan some sort of evolutionary architectural path, which would have two
phases: i) to survey all classes of stakeholders (ISP's, content providers,
users) to see what the network needs to be able to do that it can't now, and
ii) provide both a) an architecture that meets those needs, and b) a
_realistic_ plan for getting there. Realistic in economic, interoperability,
etc terms - all the things we have learned (painfully) are so critical to the
viable roll-out of new stuff.
Do note that that effort implies that the current solution _doesn't_ provide
all those things. So we might as well swallow hard and admit _that_ publicly
too.
Whether all the above is politically feasible in the current IETF - who knows?
If not, it's back to 'The Emperor's New Protocol' for another year or so, I
guess, by which time the environment may be a bit more receptive.
Noel
___
Ietf mailing list
Ietf@ietf.org
can we please postpone the ipv6 post-mortem?
everyone-- IPv6 may have been born with a developmental disability, but we're not dealing with a corpse yet. The patient is still alive, getting better, and with a bit of love and proper care, might yet grow up to make better and brighter music than IPv4. Maybe I'm being overly sentimental and using anthropomorphism inappropriately here, but really folks-- isn't it a bit unseemly to be arguing over how we went so wrong with IPv6-- and how we could do ever so much better the *next* time we get to reinvent the Internet if we avoid all the killing mistakes we made in bringing IPv6 up-- while there are, today, more people than ever before taking what are perceived to be enormous risks actually making the v4-v6 transition start to happen? -- james woodyatt j...@apple.com member of technical staff, communications engineering ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: US DoD and IPv6
Noel Chiappa wrote:
Which is why I am urging the IETF to be _realistic_ now, and accept the world
as it actually is, and set direction from here on out based on that, and not
on what we wish would happen.
The only realistic approach is to accept IPv4 at least for next
10 or 20 years, which is possible with port restricted IP while
keeping the end to end transparency.
Which means, for instance, that any design for
architecural change (e.g. introducing separation of location and identity) is
going to be somewhat ugly, because we don't have a clean sheet of paper to
work with.
ID locator separation is not essential. All we need is an architecture
to handle multiple addresses (which may be raw addresses or an ID and
multiple locators).
It also means accepting that we have multiple naming domains at
the end-end level,
It means to handle multiple IP addresses.
and will for the forseeable future;
It means to handle multiple IPv4 addresses.
and trying to work out
an architectual direction for coping with that ('get rid of it' doesn't
count). Etc, etc, etc.
The basic architectural problem so many people want to ignore
is that IP is connectionless, which means there is no time out
at the IP layer to know some address is not working.
As a result, there are a lot of wrong proposals seen in multi6
WG, which declare TCP connections are dead merely because
no traffic is observed for a while, which is no different from
poor legacy NAT violating the end to end principle.
Interestingly enough, IPv6 failed partly because its neighbor
discovery has introduced a lot of time out at the IP layer,
which is architecturally wrong (in this case, timing depends
on link layers). Requirements on RtrAdvInterval was finally
loosened in RFC3775 (MIPv6) but rest remains.
Once it is recognized that the problem of multiple addresses can
be solve only at (in case of TCP) or above (in case of UDP) the
transport layer, the solution is easy and straight forward.
Details are documented in draft-ohta-e2e-multihoming-00.txt
in Apr. 2000.
Though my experimental implementation is in IPv6 with ID/locator
separation, same is doable with (port restricted) IPv4.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: can we please postpone the ipv6 post-mortem?
+1 On 10/8/10 1:02 PM, james woodyatt j...@apple.com wrote: everyone-- IPv6 may have been born with a developmental disability, but we're not dealing with a corpse yet. The patient is still alive, getting better, and with a bit of love and proper care, might yet grow up to make better and brighter music than IPv4. Maybe I'm being overly sentimental and using anthropomorphism inappropriately here, but really folks-- isn't it a bit unseemly to be arguing over how we went so wrong with IPv6-- and how we could do ever so much better the *next* time we get to reinvent the Internet if we avoid all the killing mistakes we made in bringing IPv6 up-- while there are, today, more people than ever before taking what are perceived to be enormous risks actually making the v4-v6 transition start to happen? -- james woodyatt j...@apple.com member of technical staff, communications engineering ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: can we please postpone the ipv6 post-mortem?
On Oct 8, 2010, at 7:02 AM, james woodyatt wrote: isn't it a bit unseemly to be arguing over how we went so wrong with IPv6-- and how we could do ever so much better the *next* time we get to reinvent the Internet if we avoid all the killing mistakes we made in bringing IPv6 up-- while there are, today, more people than ever before taking what are perceived to be enormous risks actually making the v4-v6 transition start to happen? You're just setting things up for more 'I told you so's when the routing system falls over as all those folks add (not transition) IPv6 to their announcements... :-) Regards, -drc ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: can we please postpone the ipv6 post-mortem?
+1 On Oct 8, 2010, at 1:02 PM, james woodyatt wrote: everyone-- IPv6 may have been born with a developmental disability, but we're not dealing with a corpse yet. The patient is still alive, getting better, and with a bit of love and proper care, might yet grow up to make better and brighter music than IPv4. Maybe I'm being overly sentimental and using anthropomorphism inappropriately here, but really folks-- isn't it a bit unseemly to be arguing over how we went so wrong with IPv6-- and how we could do ever so much better the *next* time we get to reinvent the Internet if we avoid all the killing mistakes we made in bringing IPv6 up-- while there are, today, more people than ever before taking what are perceived to be enormous risks actually making the v4-v6 transition start to happen? -- james woodyatt j...@apple.com member of technical staff, communications engineering ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: US DoD and IPv6
On Oct 8, 2010, at 10:49 AM, John C Klensin wrote: --On Friday, October 08, 2010 09:47 -0400 Steve Crocker st...@shinkuro.com wrote: Let me say this more strongly. These two defects, it wasn't economically feasible ... and it didn't offer any interesting/desirable new capabilities were mild compared to an even bigger defect: There simply wasn't a technically feasible plan on the table for co-existence and intercommunication of IPv4 and IPv6 networks. In addition to working our way through the IPv6 adoption and co-existence process, I think it would be useful to do a little soul-searching and ask ourselves if we're so smart, how come we couldn't design a next generation IP protocol and work out a technically viable adoption and co-existence strategy. The dual stack approach implicitly assumed everyone would have both an IPv6 and an IPv4 address. If everyone has both kinds of addresses, that implicitly asserts there's no visible shortage of IPv4 addresses, which is contrary to fundamental reason IPv6 is needed. Further, although some scenarios suggest IPv4 usage will start to decline steeply once IPv6 transport, products and services are widely available, the safer bet is that IPv4 networks will persist for a fairly long time, say 20 to 50 years. Steve, While I agree with what you say (and most of what Noel says), hindsight is pretty easy. I even agree with your 20 to 50 year estimate although an optimist might draw some comfort from how quickly CLNP and CONP, TP0 and TP4 (and the rest of the OSI machinery), Vines and Netware, etc., disappeared once the network effects set in and the writing appeared on the wall. However, certainly Noel's position was part of the discussion 15-odd years ago. Certainly the positions that IPng must either be strictly forward compatible or that it should introduce enough new and valuable functionality to make people want to incur the pain were part of the discussion. Nonetheless, the IETF community selected what is now IPv6. What does this say about the IETF and how we make decisions? Does that need adjusting? Finally, and perhaps more important right now, while it is easy to observe that the 1995 (or 2000) predictions for IPv6 deployment rates have not come close to being satisfied and recriminations based on hindsight may be satisfying in some ways, the question is what to do going forward. There are communities out there who believe that we have managed to prove that datagram networks, with packet-level routing, are a failure at scale and that we should be going back to an essentially connection-oriented design at the network level. I think that many, perhaps most, of the people who believe that would believe it regardless of the facts on the ground. Regards Marshall If they were to be right, then it may be that we are having entirely the wrong discussion and maybe that we are on the wrong road (sic) entirely. If not, then there are other focused discussions that would be helpful. The latter discussions that have almost started in this and related threads, but have (I believe) gotten drowned out by the noise, personal accusations about fault, and general finger-pointing. How would you propose moving forward? john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: can we please postpone the ipv6 post-mortem?
Another +1 from me. And with respect to the alleged mistake made 15 years ago, two facts may help: 1. The transition model was complete - because it was based on vendors and ISPs supporting dual stack globally well *before* IPv4 exhaustion. It's because that didn't happen that we have a bit of a panic now. It didn't happen because short term economic incentives triumphed over enlightened self interest. Fine, lesson learned, let's move on, which the ISPs are now doing. 2. There is, mathematically and logically, no 'backwards compatible' IP with bigger addresses than IPv4. That's because IPv4 doesn't contain any provision for extensible addresses. So please let's not hear complaints that IPvN isn't backwards compatible; it never could have been and never will be, and that is the fault of the IPv4 design. So the issue of interworking between legacy IPv4-only systems and the world of bigger addresses is an unavoidable fact of the physical universe. Which is why BEHAVE is currently doing NAT64. Regards Brian Carpenter On 2010-10-09 06:02, james woodyatt wrote: everyone-- IPv6 may have been born with a developmental disability, but we're not dealing with a corpse yet. The patient is still alive, getting better, and with a bit of love and proper care, might yet grow up to make better and brighter music than IPv4. Maybe I'm being overly sentimental and using anthropomorphism inappropriately here, but really folks-- isn't it a bit unseemly to be arguing over how we went so wrong with IPv6-- and how we could do ever so much better the *next* time we get to reinvent the Internet if we avoid all the killing mistakes we made in bringing IPv6 up-- while there are, today, more people than ever before taking what are perceived to be enormous risks actually making the v4-v6 transition start to happen? -- james woodyatt j...@apple.com member of technical staff, communications engineering ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Internet Architecture (was US DoD and IPv6)
From: Dave Cridland d...@cridland.net So currently, a NAT provides: - A degree of de-facto firewalling for everyone. - An immunity to renumbering for enterprises. - Fully automated network routing for ISPs. If technologies could be introduced to tackle especially the last two, I think the advantages of NATs would vanish. Even assuming we could provide 1-3 above in some way (which I am somewhat dubious about), I would have to say 'I don't think so' to your conclusion - because I think your list is incomplete. The Internet as actually deployed depends crucially on having a number of disjoint low-level naming realms - which necessitate NAT boxes between them. For one, my understanding of the current plan for interoperability between IPv6 devices with an IPv6-only address, and 'the' IPv4 Internet, is the 'IPv4/IPv6 Translation' work from BEHAVE, and that's basically NAT. (There was, a long time ago, some proposal for having such IPv6 devices with an IPv6-only address 'share' an IPv4 address, to enable access to 'the' IPv4 Internet, but I guess it never came through.) On that alone, NATs will be with us for decades to come. For another, there are lots of people who have networks behind NAT boxes, for a variety of reasons (maybe they couldn't get the address space, maybe - like all those home wireless networks - it was just easier to do it that way). And there is, for most of them, no economic incentive to change that, to give up their private naming realm. (Sure, there will be a few exceptions, for whome it does make economic sense to get rid of NAT - e.g. large ISPs for whom NAT hacks make life too complex - but there will still be a lot left after that. So unless you have a viable scenario in which disjoint naming realms go away, then you do not have a viable scenario in which NATs go away. Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: can we please postpone the ipv6 post-mortem?
On 10/8/10 1:02 PM, james woodyatt j...@apple.com wrote: everyone-- IPv6 may have been born with a developmental disability, but we're not dealing with a corpse yet. The patient is still alive, getting better, and with a bit of love and proper care, might yet grow up to make better and brighter music than IPv4. Maybe I'm being overly sentimental and using anthropomorphism inappropriately here, but really folks-- isn't it a bit unseemly to be arguing over how we went so wrong with IPv6-- and how we could do ever so much better the *next* time we get to reinvent the Internet if we avoid all the killing mistakes we made in bringing IPv6 up-- while there are, today, more people than ever before taking what are perceived to be enormous risks actually making the v4-v6 transition start to happen? James, I don't see this as a post-mortem. I still expect to see IPv6 widely deployed and certainly do not agree with anyone who thinks it is time to pull the plug on it (or that we should have done so several years ago). However, I believe that the essence of competent engineering involves trying to see whole systems, to understand risk factors and make contingency plans, and to be sure that we are not responding to transitional issues with wishful thinking alone. I don't think we are doing some of those things as well as we need to. I also think we have made some assumptions along the way that come close to the old cartoon about how one gets from Step 3 to Step 5 by writing down magic happens or pretending that it is somehow intuitively obvious. While I can't speak for anyone else, I see my comments as a plea that we not try to solve problems by stuffing our heads in the sand like the proverbial ostrich, hoping that the problems will have magically disappeared by the time we pull it out. I think that is important whether one's favorite problem from which to try to hide is the danger of routing collapse when both IPv4 and IPv6 addresses need to be advertised; the inability of applications to meet implicit IPv6 assumptions about choices of addresses and, through them, routes; our inability to get rid of NATs or applications-layer knowledge of addresses or to design better ways to co-exist with them; or something else. While I wish there were a lot less apparent rancor and I told you so tone in this conversation, I don't believe that the underlying issues can be dismissed by talking about what is, or is not, seemly or by keeping silent because a lot of folks are making major investments. My hope is that, by asking these questions now, we can be certain that all of the other ducks are lined up to make IPv6 --as seen by the users and those who sign the checks -- work really well after we get past the stages with which those investments are involved. And, again, I think that is ultimately an optimistic message about our finally doing good and realistic engineering to finish the puzzle of which IPv6 itself is a critical component, not a post-mortem on IPv6. best, john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: can we please postpone the ipv6 post-mortem?
From: james woodyatt j...@apple.com the v4-v6 transition There isn't going to be an v4-v6 transition. If you're lucky, there will be a very long (many decades) period of IPv4/IPv4 interoperability. Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: can we please postpone the ipv6 post-mortem?
+1 Bob On Oct 8, 2010, at 12:36 PM, Brian E Carpenter wrote: Another +1 from me. And with respect to the alleged mistake made 15 years ago, two facts may help: 1. The transition model was complete - because it was based on vendors and ISPs supporting dual stack globally well *before* IPv4 exhaustion. It's because that didn't happen that we have a bit of a panic now. It didn't happen because short term economic incentives triumphed over enlightened self interest. Fine, lesson learned, let's move on, which the ISPs are now doing. 2. There is, mathematically and logically, no 'backwards compatible' IP with bigger addresses than IPv4. That's because IPv4 doesn't contain any provision for extensible addresses. So please let's not hear complaints that IPvN isn't backwards compatible; it never could have been and never will be, and that is the fault of the IPv4 design. So the issue of interworking between legacy IPv4-only systems and the world of bigger addresses is an unavoidable fact of the physical universe. Which is why BEHAVE is currently doing NAT64. Regards Brian Carpenter On 2010-10-09 06:02, james woodyatt wrote: everyone-- IPv6 may have been born with a developmental disability, but we're not dealing with a corpse yet. The patient is still alive, getting better, and with a bit of love and proper care, might yet grow up to make better and brighter music than IPv4. Maybe I'm being overly sentimental and using anthropomorphism inappropriately here, but really folks-- isn't it a bit unseemly to be arguing over how we went so wrong with IPv6-- and how we could do ever so much better the *next* time we get to reinvent the Internet if we avoid all the killing mistakes we made in bringing IPv6 up-- while there are, today, more people than ever before taking what are perceived to be enormous risks actually making the v4-v6 transition start to happen? -- james woodyatt j...@apple.com member of technical staff, communications engineering ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF-ad-hominem (Was: Re: US DoD and IPv6)
On 10/6/2010 10:04 PM, Richard L. Barnes wrote: NEW NON-IETF LIST ANNOUNCEMENT IETF Ad Hominem Discussions This group is dedicated to the discussion of the personal flaws of IETF participants. Such a fertile thread you've created. So much to play with... If I want to say that this new list is a foolish idea and you are being hopelessly naive in creating it -- and thereby I am crossing into ad homimen... or am I -- must I do that on the new list that I disapprove of or should I do it here, where its formation is announced? To the extent that there is a hint of seriousness to my post, I'll merely note that expecting folks to a) acknowledge that they are making an ad hominem, and b) choose to move to another venue is, ummm... a tad idealistic, given the emotions and style that tend to be present in a poster who is making ad hominem comments. So I applaud your goal, but can't imagine its being achieved. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: existing (and questionable) application designs [was Re: US DoD and IPv6]
All true, but based on the information available at the time, I am not sure how a different outcome would have been arrived at. Having a group to make unpopular but right decisions always seems a great idea in hindsight. But there is a real practical difficulty distinguishing such groups form similar groups whose ideas are both unpopular and wrong. The reason the IAB has no authority is that the selection mechanism is designed to ensure that it has no accountability. No accountability means no authority. What you seem to be saying is that the IETF should have made deployment a much higher priority in the design of IPv6. Which is what I have been saying for years. I treat deployment as an engineering problem. I have been constructing models and running simulations to test various approaches to deployment since 1992. I can construct a plausible deployment model for IPv6 based on NAT boxes. But I can't see a plausible model which does not involve NAT44, NAT46 and NAT66 during the transition period and since I am anticipating that lasting around thirty years, I can't see much point in modeling what comes after. On Thu, Oct 7, 2010 at 10:58 AM, Keith Moore mo...@network-heretics.comwrote: On Oct 7, 2010, at 10:20 AM, Noel Chiappa wrote: From: Brian E Carpenter brian.e.carpen...@gmail.com The problem is that the creation of disjoint addressing realms (due to NAT and to IPv4/IPv6 coexistence) has made distributed application design almost impossible without kludges. See, this is the kind of thing I was talking about in my early post in the recent incarnation of this thread. Complaining about the existence of disjoint naming realms, and how it has complicated our lives, is like a rocket scientist complaining about gravity, and how hard it makes their job. (OK, it's not quite a perfect analogy, since gravity is fundamental, but I think my point is clear.) They were inevitable, end of story. No, they were not inevitable, at least not in the long term. Two cases: 1. There were IPng proposals that would have made IPng an extension of IPv4 space, and allowed (at least in the interim) all IPng traffic to be tunneled over IPv4 networks. This understandably made routing people and network operators uneasy as nobody wanted to live with the Class C swamp forever. But in hindsight there were probably other ways of dealing with that problem. And being able to leverage the existing IPv4 network in a general way would have made IPng easier to deploy. (Admittedly, what looked deployable in the early 1990s when these tradeoffs were being discussed is very different from what looks deployable now. In 1991, say, it was much easier to imagine the whole Internet migrating to a new protocol than it was even a couple of years later.) 2. In the late 1990s when it became apparent that NATs were causing problems, IETF had an opportunity to put a stake in the ground. It could have tried to find a way to integrate NATs into an explicit Internet architecture; it could have explained why NATs presented difficult problems for which there were no good solutions; it could have tried to define NAT in such a way as to permit a more graceful migration to IPv6. It failed at all three of these, not because of insurmountable technical difficulties, but because (a) too many people were afraid of alienating NAT vendors, and (b) IAB, the only part of IETF that had any responsibility for architectural direction, had been stripped of its power in the wake of Kobe. In fact, as we should realize by now, IAB's concerns that dictated the Kobe decision were extremely well founded, even if a lot of us (myself included) didn't like the specific choice they made. But as it turned out, we didn't really have enough time to use our normal rough consensus process to specify IPng. All of this is water that has already flowed under the bridge, of course. But I think there is at least one thing that we need to learn from this going forward, and that is that there really is a need for a small group of wise and widely-trusted people to be able to set architectural direction for the internet. And occasionally, they're going to make unpopular decisions. But those are the sort of issues for which a rough consensus process demonstrably does not work. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Website: http://hallambaker.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: US DoD and IPv6
[Replying to John, Steve, others] This might sound like a completely off the wall suggestion. But is it possible that we could use an IPv4 extension header to carry the internal address of a NAT-ed host in some way and thus preserve end-to-end addressability? Assume for the sake of argument that we have a secure DNS deployed and that this scheme makes it efficient to publish policy records for protocols. [I have a detailed justification for why this is possible]. Such that when a client attempts to connect to the http protocol for www.example.com it is going to receive back a DNS record chain from its resolver that includes: www.example.com A18.1.1.1 AA 18.1.1.1.10.1.0.0 _http._tcpESRVIP=a+aa+ If the application is going to use the AA record it has to have an IPv4.1 stack. This causes it to emit IPv4 packets where the first four bytes are sent in the IPv4 header and the remaining four bytes are sent as a header option. The NAT box at 18.1.1.1 now has all the information it requires to allow complete transparency in either direction. Clients can connect to a server behind a NAT box provided only that they have a current IP stack. I can even provide a pretty good solution to Brian's mobility/referral problem. Say that there are 256 points of presence, each of which has a distinct IPv4 address. All we need to do is to tell the mobile device when to change its Internet point of presence address. The target need not know that the gateway has been changed. Of course one objection that would be made against this is likely to be that it solves the problem a bit too well and eliminates the need for IPv6 entirely. The other objection is going to be that we are now so far into the deployment of IPv6 that 'it is too late to change'. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: can we please postpone the ipv6 post-mortem?
What if the key to IPv6 deployment is the realization that IPv6 can only be deployed after we have solved the IPv4 address exhaustion problem? On Fri, Oct 8, 2010 at 1:02 PM, james woodyatt j...@apple.com wrote: everyone-- IPv6 may have been born with a developmental disability, but we're not dealing with a corpse yet. The patient is still alive, getting better, and with a bit of love and proper care, might yet grow up to make better and brighter music than IPv4. Maybe I'm being overly sentimental and using anthropomorphism inappropriately here, but really folks-- isn't it a bit unseemly to be arguing over how we went so wrong with IPv6-- and how we could do ever so much better the *next* time we get to reinvent the Internet if we avoid all the killing mistakes we made in bringing IPv6 up-- while there are, today, more people than ever before taking what are perceived to be enormous risks actually making the v4-v6 transition start to happen? -- james woodyatt j...@apple.com member of technical staff, communications engineering ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Website: http://hallambaker.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: can we please postpone the ipv6 post-mortem?
Brian E Carpenter wrote: 1. The transition model was complete - because it was based on vendors and ISPs supporting dual stack globally well *before* IPv4 exhaustion. Huh? Hardly anyone support IPv6 these days. Sony KDL40*X70* internet-enabled LED-LCD-TV, 2010, IPv4-only (bought 7/2010) Western Digital MyBookWorld2 HomeNAS, 2009, IPv4-only Nintendo WII appears to be IPv4-only 95% of all home-DSL-Routers in Germany IP (100% from the folks I know) are IPv4 only. most home users in Germany can not even get IPv6 from their ISP, even when they had an IPv6-capable DSL-router. What capabilities there are available on the internet backbone or what could be enabled on newer operating systems by sophisticated end users doesn't matter much, if most of the internet-enabled end user equipment, that is being sold to consumers, is still IPv4-only. What we desperately need is factory-enabled transparent internetworking on all _NEW_ networking equipment and internet-enabled gadgets and appliances. As long as IPv4 and IPv6 are seperate worlds the hen-and-egg stalemate is going to continue. And the useful lifetime of all brand-new IPv4-only equipment that is produced by the electronic entertainment industry is about 5-15 years. -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: US DoD and IPv6
On Fri Oct 8 17:49:28 2010, Keith Moore wrote: On Oct 8, 2010, at 12:31 PM, Dave Cridland wrote: On Fri Oct 8 17:10:56 2010, Keith Moore wrote: Except that neither middleboxes in general nor NATs in particular were a direct result of the decision to adopt IPv6. NATs were not originally driven by a shortage of IPv4 addresses. In the consumer market they were driven by what came to be a de facto standard of one IP address per customer, due partially to this assumption being widespread within IETF itself. In the enterprise network space they were initially driven by a misguided notion that having private addresses would produce better network security. In both cases the adoption of NATs was largely a consequence of IETF's failure to produce and adhere to a comprehensive plug-and-ping autoconfiguration architecture. Oh, I think there's rather more than that. Of course there is, but I was trying to be brief. Oh, sure, but I think the points you glossed over in that effort were more significant that the points you retained. Initially, NATs came about because enthusiasts found that it was prohibitively expensive to get a routed block down a modem - the ISPs treated you like a business customer, and charged accordingly. But part of that was because single-address-per-customer (or dialin session) was naturally a commodity service, while routing a block down a modem was something that required special-case handling at the ISP. And I think it's fair to say that that was the assumption in IETF also. I don't recall any efforts toward autoconfiguration of networks then, particularly not for those connected via point-to-point links. It's hard to not blame the ISPs for wanting to charge differently for one-address dialin vs. other accounts that required more customization, setup, and support on their part. Absolutely, and I basically stated that later - that's why the ISPs changed from actively trying to supress such usage into actively supporting it, because it meant that network setups became, from their viewpoints, free. As NATs drifted into the enterprise, there was a security angle, but there was also a renumbering angle that still hasn't gone away. This is, in no small part, because the only way to refer to an arbitary network is via the addressing - actual hosts are largely dealt with by a combination of DHCP and DNS. (As a random thought, if there was a CIDR DNS RR, I wonder if this may help?) Not sure what you mean by a CIDR DNS RR, but I hope it's nothing like A6 / DPTR was. In IPv4 terms a DNS RR that meant I could lookup what dave.cridland.net's network was, and get back 217.155.137.156/29, and therefore use the network name instead of the IP addresses in configuration, such as firewalling rules, DHCP server config, etc. I vaguely recall the A6/DPTR combination as being rather more ambitious than that, but really, a search/replace on a zonefile during a renumber is pretty easy. It's the hunting down the network references in router configs and firewall rules that's the pain. There is occasional rumblings within the IETF to address this, but given NATs have to some extent removed the bulk of the pain, I'm not sure there's sufficient motivation to solve all the issues. And there's always considerable pressure on and within IETF to just embrace NAT for this. Right - it's a vicious circle, too, because we must embrace NAT because no other solution exists, but there's no point developing a better solution because NAT exists. Unfortunately, renumbering still happens even when you're using 10/8, so NAT doesn't answer all the cases. So currently, a NAT provides: - A degree of de-facto firewalling for everyone. - An immunity to renumbering for enterprises. - Fully automated network routing for ISPs. If technologies could be introduced to tackle especially the last two, I think the advantages of NATs would vanish. But the NATs are good mentality would still be widespread.Old timers hate to learn how to use new tools, even if the old tools are crap. Right, and we need to work around that damage with stuff like BEHAVE, and careful application design. Still, to my mind, I have the feeling that end-to-end addressing could actually be a security and reliability benefit to many peer-to-peer applications (VOIP and IM file transfer being just two that spring to mind), so there could be interest in getting there from here. Moreover, if we tackle the renumbering and automated routing case (and I think the latter is largely done - not my area though) then we've provided the tools for home and enterprise alike to ween themselves off NAT quite effectively. Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP,
Re: US DoD and IPv6
On Fri Oct 8 16:14:02 2010, Phillip Hallam-Baker wrote: If the application is going to use the AA record it has to have an IPv4.1 stack. This causes it to emit IPv4 packets where the first four bytes are sent in the IPv4 header and the remaining four bytes are sent as a header option. Can't one then use a DNS lookup which tells it a tunnel endpoint for an IPv6-in-IPv4 tunnel, and provide transparent IPv6 at both ends? This could be implemented entirely at the network edge, eliminating the need for special stacks at the endpoints. Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: can we please postpone the ipv6 post-mortem?
Brian E Carpenter wrote: Another +1 from me. And with respect to the alleged mistake made 15 years ago, two facts may help: You are saying it's not post-mortem but vivisection. OK. 2. There is, mathematically and logically, no 'backwards compatible' IP with bigger addresses than IPv4. Your statement is unfounded. Port restricted IP is the mathematical and logical IP with bigger *APPLICATION* address than IPv4 with full backward compatibility. So the issue of interworking between legacy IPv4-only systems and the world of bigger addresses is an unavoidable fact of the physical universe. As the address space for transport and application layers is address+protocol+port, the space is identical with both IPv4 and port restricted IPv4. Thus, iterworking between IPv4 and PR-IPv4 just works. Which is why BEHAVE is currently doing NAT64. With the existence of PR-IPv4, IPv6 including NAT64 is denied, mathematically and logically. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: can we please postpone the ipv6 post-mortem?
Noel Chiappa wrote: There isn't going to be an v4-v6 transition. If you're lucky, there will be a very long (many decades) period of IPv4/IPv6 interoperability. +1 Phillip Hallam-Baker wrote: I can construct a plausible deployment model for IPv6 based on NAT boxes. But I can't see a plausible model which does not involve NAT44, NAT46 and NAT66 during the transition period and since I am anticipating that lasting around thirty years, I can't see much point in modeling what comes after. +1 This might sound like a completely off the wall suggestion. But is it possible that we could use an IPv4 extension header to carry the internal address of a NAT-ed host in some way and thus preserve end-to-end addressability? The problem with IP with IP extensions is that too often, sooner or later they have to be implemented in silicon on the high-end platform. The not invented here syndrome may be a significant obstacle if it does not come from within a prominent router vendor. Of course one objection that would be made against this is likely to be that it solves the problem a bit too well and eliminates the need for IPv6 entirely. The other objection is going to be that we are now so far into the deployment of IPv6 that 'it is too late to change'. That too. What if the key to IPv6 deployment is the realization that IPv6 can only be deployed after we have solved the IPv4 address exhaustion problem? I suspect that people with vested interests in IPv6 will not like this idea, as solving the v4 exhaustion problem would eliminate a considerable incentive to deploy v6 and create a threat to the very existence of v6. In any case, I don't think anything is going to happen for at least 3 years. As of today we are in the waiting game; we have to let IPv4 exhaust and assess who is hurting and how much pain everyone feels. Michel. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: can we please postpone the ipv6 post-mortem?
Martin Rex wrote: most home users in Germany can not even get IPv6 from their ISP, even when they had an IPv6-capable DSL-router. Curiously enough, our biggest and almost monopoly because most others depend on them - dtag.de - released: first half of 2011 they will start upward and peering IPv6. Second half of 2011 everybody will be connected dual stack and fixed addresses for both IPv4 and IPv6. There is rumour that home users will get IPv4 addresses only in the 10.x.x.x address space. IPv6 will be /56. Kind regards Peter -- Peter and Karin Dambier Cesidian Root - Radice Cesidiana Rimbacher Strasse 16 D-69509 Moerlenbach-Bonsweiher +49(6209)795-816 (Telekom) +49(6252)750-308 (VoIP: sipgate.de) mail: pe...@peter-dambier.de http://www.peter-dambier.de/ http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/ ULA= fd80:4ce1:c66a::/48 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: can we please postpone the ipv6 post-mortem?
On 2010-10-09 11:42, Martin Rex wrote: Brian E Carpenter wrote: 1. The transition model was complete - because it was based on vendors and ISPs supporting dual stack globally well *before* IPv4 exhaustion. Huh? Hardly anyone support IPv6 these days. Sorry Martin, to write it more clearly: The transition model in 1995 was based on the assumption that vendors and ISPs would support dual stack globally well *before* IPv4 exhaustion. The fact that this did not happen is the problem. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: can we please postpone the ipv6 post-mortem?
On Oct 8, 2010, at 3:42 PM, Martin Rex wrote: Huh? Hardly anyone support IPv6 these days. Well, the hardly anyone seems to include all Windows, Macosx, Linux, and Freebsd-based products, and routers from any vendor you care to name. But hardly anyone includes Canon printers like the one sitting next to me, all products from Sony that have a network interface (think Blue-Ray players, PS2, PS3, ...), Ericsson and Nokia telephones, Android 2.1 and later, iPhone OS 4 (in which it apparently can't be turned off), Yes, CPEs are a problem right now. Look for that to change. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
