RE: Deployment Cases
"Hallam-Baker, Phillip" <pbaker@verisign.com> Thu, 03 January 2008 16:31 UTC
Return-path: <ietf-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JASyI-0008KN-3q; Thu, 03 Jan 2008 11:31:06 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JASyG-0008KF-De for ietf@ietf.org; Thu, 03 Jan 2008 11:31:04 -0500
Received: from robin.verisign.com ([65.205.251.75]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JASyE-0002QL-Ql for ietf@ietf.org; Thu, 03 Jan 2008 11:31:04 -0500
Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by robin.verisign.com (8.12.11/8.13.4) with ESMTP id m03GObtf029900; Thu, 3 Jan 2008 08:24:37 -0800
Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Jan 2008 08:30:59 -0800
Content-class: urn:content-classes:message
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Thu, 03 Jan 2008 08:30:59 -0800
Message-ID: <2788466ED3E31C418E9ACC5C31661557084FCB@mou1wnexmb09.vcorp.ad.vrsn.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Deployment Cases
Thread-Index: AchN9bC36d82ycDNQxWiPRblumPZgQALYH8i
References: <2788466ED3E31C418E9ACC5C316615570462E8@mou1wnexmb09.vcorp.ad.vrsn.com><066001c84892$a33f7850$6601a8c0@china.huawei.com><4774103E.4000407@dcrocker.net><AFE0AC8DCDE68842B94E8EC69D5F21D635E6CD4501@NA-EXMSG-W602.wingroup.windeploy.ntdev.microsoft.com><47744661.3060808@bbiw.net><47749A8B.1080502@sopac.org><9BE39E8B-7B1F-4243-985C-025A24D105EB@muada.com><47794C95.7050005@dcrocker.net><1474DFBA-8B77-46B8-AABA-373689555331@cs.columbia.edu><47795548.7000303@bbiw.net><66006D08-6F13-4BDF-8960-3D747F44FB0E@cs.columbia.edu><477970FE.8090302@sopac.org><01MPJP2QLGWE00BDC1@mauve.mrochek.com> <2788466ED3E31C418E9ACC5C31661557084FC2@mou1wnexmb09.vcorp.ad.vrsn.com> <D03E4899F2FB3D4C8464E8C76B3B68B001AB742C@E03MVC4-UKBR.domain1.systemhost.net> <477C2B52.8040408@spaghetti.zurich.ibm.com> <D03E4899F2FB3D4C8464E8C76B3B68B001AB753F@E03MVC4-UKBR.domain1.systemhost.net> <477CBC70.6080402@spaghetti.zurich.ibm.com>
From: "Hallam-Baker, Phillip" <pbaker@verisign.com>
To: Jeroen Massar <jeroen@unfix.org>, michael.dillon@bt.com
X-OriginalArrivalTime: 03 Jan 2008 16:30:59.0308 (UTC) FILETIME=[05CCA2C0:01C84E26]
X-Spam-Score: 1.8 (+)
X-Scan-Signature: 3f3e54d3c03ed638c06aa9fa6861237e
Cc: ietf@ietf.org
Subject: RE: Deployment Cases
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0690406258=="
Errors-To: ietf-bounces@ietf.org
Yes, as you point out the generic answer to the problem is NAT-PT which was recently squashed after a cabal got together. My point here is that the thinking on the transition in the IETF to date has all been of the form 'well everyone is going to have to become like us, only they can't possibly expect to so its a bit of a problem but not our problem'. I received a lot of criticism when I first proposed that the IETF embrace NAT as a transition tool rather than deprecate it. The idea that we should actively encourage the NAT-ing of IPv4 was considered as unacceptable as Brian and others now find my proposals for changing the way that the IETF operates and the considerations it takes into account. I don't see much dispute on that point today. Pretty much everyone seems to now accept that we are going to run out of IPv4 addresses before IPv6 deployment is complete and that some form of address sharing is therefore inevitable. What we have failled to do so far is to act on that. Take a look at what has happened in the film industry, the camera film industry that is. Every manufacturer of 35mm film has understood that digital would replace film in the consumer market shortly after 2005, that studios would have transitioned from 35mm to digital by 2010 and that distribution of 35mm prints will effectively cease by 2015. Virtually everyone in that business understands exactly what the story is. Then take a look at what those companies are doing about it. Polaroid has already gone bankrupt and Kodak is desperately trying to re-invent itself as a digital photography provider in time. Both companies understood what would happen to their market and the new technologies that would come in. But neither company ever made a serious attempt to become Sandisc. Yes, whole industries can and do march right off a cliff in lockstep even when they see the cliff comming. ________________________________ From: Jeroen Massar [mailto:jeroen@unfix.org] Sent: Thu 03/01/2008 5:44 AM To: michael.dillon@bt.com Cc: ietf@ietf.org Subject: Re: Deployment Cases michael.dillon@bt.com wrote: >>> Unless I've missed something recent, the IETF did not do a >> lot of work >>> on the scenario where IPv4 islands need to communicate over an IPv6 >>> Internet, talking to both IPv4 and IPv6 services. >> It is called dual-stack. > > That seems to simply ignore the issue by saying, let there be IPv4 > everywhere for those who need it. But if there are not enough > addresses to grow the IPv4 infrastructure, you can't have IPv4 > everywhere. > >> The big question of course is: what exact problem do you want >> to solve? > > An IPv4 island, that is blissfully unaware of the IPv4 address > crunch until far too late, wants to avoid changing their network > but still maintain connectivity to both the IPv6 and the IPv4 > Internet. They may have to connect to an IPv6 ISP (for instance > if their IPv4 ISP goes bankrupt or they move an office location) > or they may connect to an IPv4 ISP who peers with a dual-stack > ISP or 6PE ISP. How do they continue to access all Internet services > from their IPv4 island, regardless of whether or not the services > are using IPv6 only? What is so difficult in going dual-stack? IPv4 is NATted, as it already is at a lot of places, and IPv6 comes in there using a tunnel. Most 'services' that people use over the internet, fall under either: - HTTP -> Use a HTTP Proxy with both IPv4 & IPv6 - SMTP -> Use a SMTP server which supports both IPv4 & IPv6 Anything else? Not really. As such, which exact services do you want to transition? > Note that this is rather similar to the question raised regarding > the IPv4 outage at an IETF meeting. How does an IPv4 laptop user > continue to function without interruption when only IPv6 Internet > access is available at an IETF meeting? As your source address breaks the moment your connection is interrupted your have an interruption already. But you probably mean so that they can continue using service X, well first start by defining service X. The generic answer is of course NAT-PT, but there is a big reason why we don't want that. Another trick is totd and there are a number of these transition functions which are already in place and in use for a long long time. As such the sole problem left, which is going to be resolved soon, is DNS, we will finally have AAAA in the root, next step DNSSEC :) [..] >> Stating "I want to connect from IPv4 to IPv6", can mean a lot >> of things, is this HTTP? SMTP? or do you really want a >> generic solution? > > A generic solution that will work for all TCP and UDP protocols. NAT-PT, but NAT doesn't understand all the protocols, if it did, then we would not have to go to IPv6 in the first place. > I don't believe that there is an IETF solution for this scenario > which I expect to be a very common scenario specifically because > transition to IPv6 is being triggered by an IPv4 address shortage > whose effects will be felt first in the network core and ripple > outward from there. As you clearly believe that there is no such thing, then make a list of all the things you have tried and where they fail to meet your requirements. Then make a list of the requirements you are missing and propose that we solve that problem. Greets, Jeroen
_______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
- Re: Deployment Cases Rémi Després
- Re: Deployment Cases Marc Manthey
- Re: Deployment Cases Rémi Després
- Deployment Cases Hallam-Baker, Phillip
- Re: Deployment Cases Brian E Carpenter
- Re: Deployment Cases Franck Martin
- Re: Deployment Cases Hallam-Baker, Phillip
- Re: Deployment Cases Spencer Dawkins
- Re: Deployment Cases Brian E Carpenter
- Re: Deployment Cases Dave Crocker
- RE: Deployment Cases Christian Huitema
- Re: Deployment Cases Dave Crocker
- Re: Deployment Cases Franck Martin
- Re: Deployment Cases TS Glassey
- Re: Deployment Cases Iljitsch van Beijnum
- Re: Deployment Cases Dave Crocker
- Re: Deployment Cases Henning Schulzrinne
- Re: Deployment Cases Dave Crocker
- Re: Deployment Cases Henning Schulzrinne
- Re: Deployment Cases Franck Martin
- Re: Deployment Cases Ned Freed
- Re: Deployment Cases Julian Reschke
- Re: Deployment Cases Dave Crocker
- Re: Deployment Cases Iljitsch van Beijnum
- Re: Deployment Cases Dave Crocker
- Re: Deployment Cases Dave Crocker
- Re: Deployment Cases Tony Finch
- RE: Deployment Cases Ping Pan
- Re: Deployment Cases Franck Martin
- RE: Deployment Cases Ping Pan
- Re: Deployment Cases Franck Martin
- RE: Deployment Cases Hallam-Baker, Phillip
- RE: Deployment Cases Hallam-Baker, Phillip
- Re: Deployment Cases Iljitsch van Beijnum
- RE: Deployment Cases Tony Finch
- Re: Deployment Cases Joel Jaeggli
- RE: Deployment Cases Ping Pan
- RE: Deployment Cases michael.dillon
- Re: Deployment Cases Jeroen Massar
- Re: Deployment Cases Tony Hansen
- Re: Deployment Cases Stewart Bryant
- RE: Deployment Cases michael.dillon
- Re: Deployment Cases Jeroen Massar
- RE: Deployment Cases Hallam-Baker, Phillip
- Re: Deployment Cases Iljitsch van Beijnum
- Re: Deployment Cases Brian E Carpenter
- RE: Deployment Cases Hallam-Baker, Phillip
- Re: Deployment Cases Lars Eggert
- Re: Deployment Cases Marshall Eubanks
- RE: Deployment Cases Hallam-Baker, Phillip