Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT
Alexandru Petrescu <alexandru.petrescu@gmail.com> Sun, 15 February 2015 19:47 UTC
Return-Path: <alexandru.petrescu@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 901881A00E7 for <v6ops@ietfa.amsl.com>; Sun, 15 Feb 2015 11:47:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.717
X-Spam-Level: **
X-Spam-Status: No, score=2.717 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, SPF_SOFTFAIL=0.665] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9UgZSFDNtXE for <v6ops@ietfa.amsl.com>; Sun, 15 Feb 2015 11:47:19 -0800 (PST)
Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [IPv6:2a01:e0c:1:1599::13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21DFA1A00E5 for <v6ops@ietf.org>; Sun, 15 Feb 2015 11:47:19 -0800 (PST)
Received: from [127.0.0.1] (unknown [82.229.156.225]) by smtp4-g21.free.fr (Postfix) with ESMTP id 7B3FA4C8089; Sun, 15 Feb 2015 20:47:05 +0100 (CET)
Message-ID: <54E0F7C3.3050500@gmail.com>
Date: Sun, 15 Feb 2015 20:47:15 +0100
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Ca By <cb.list6@gmail.com>
References: <20150212124226.3282.9774.idtracker@ietfa.amsl.com> <54DCD464.3000907@gmail.com> <787AE7BB302AE849A7480A190F8B93300490A7DD@OPEXCLILM23.corporate.adroot.infra.ftgroup> <6536E263028723489CCD5B6821D4B21303DEA4B0@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DDF37D.1050405@gmail.com> <6536E263028723489CCD5B6821D4B21303DEA605@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DE0BA8.8020908@gmail.com> <6536E263028723489CCD5B6821D4B21303DEA722@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DE227D.9050303@gmail.com> <CAD6AjGRCvc314QaiGfMGLF2Wakn8ueQK55E-sxw3qW4FXLApOw@mail.gmail.com> <54DE3C45.9080806@gmail.com> <CAD6AjGRAp=Ak7v7rSmtov0cL3e_PVtwaDKZS2ZRj3ish2QeZOA@mail.gmail.com>
In-Reply-To: <CAD6AjGRAp=Ak7v7rSmtov0cL3e_PVtwaDKZS2ZRj3ish2QeZOA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Antivirus: avast! (VPS 150215-0, 15/02/2015), Outbound message
X-Antivirus-Status: Clean
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/5wnImdZftRGByPwv6m_D1Br3vDo>
Cc: "v6ops@ietf.org" <v6ops@ietf.org>
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 15 Feb 2015 19:47:23 -0000
On 13/02/2015 20:19, Ca By wrote: > > > On Fri, Feb 13, 2015 at 10:02 AM, Alexandru Petrescu > <alexandru.petrescu@gmail.com <mailto:alexandru.petrescu@gmail.com>> wrote: > > Le 13/02/2015 18:37, Ca By a écrit : > > > > On Fri, Feb 13, 2015 at 8:12 AM, Alexandru Petrescu > <alexandru.petrescu@gmail.com > <mailto:alexandru.petrescu@gmail.com> > <mailto:alexandru.petrescu@__gmail.com > <mailto:alexandru.petrescu@gmail.com>>> wrote: > > Le 13/02/2015 16:33, Heatley, Nick a écrit : > > > > -----Original Message----- From: Alexandru Petrescu > [mailto:alexandru.petrescu@ > <mailto:alexandru.petrescu@>__g__mail.com <http://gmail.com> > <mailto:alexandru.petrescu@__gmail.com > <mailto:alexandru.petrescu@gmail.com>>] Sent: 13 February 2015 14:35 > To: Heatley, Nick; mohamed.boucadair@orange.com > <mailto:mohamed.boucadair@orange.com> > <mailto:mohamed.boucadair@__orange.com > <mailto:mohamed.boucadair@orange.com>> Cc: v6ops@ietf.org > <mailto:v6ops@ietf.org> > <mailto:v6ops@ietf.org <mailto:v6ops@ietf.org>> > Subject: Re: [v6ops] I-D Action: > draft-ietf-v6ops-mobile-____device-profile-17.txt - > C_REC#9 464XLAT > > > Le 13/02/2015 14:14, Heatley, Nick a écrit : > > Hi Alex, Yes, that is wrong. You can ping any IPv4 > literal > from a > 464xlat device. My handset only has an IPv6 address > + CLAT > and I am > pinging 8.8.8.8 :-)) > > > Ok, I see. I didnt know CLAT-on-device was required > when using > v6-only APNs. > > [Heatley, Nick] For service continuity with IPv4, on an > IPv6-only > bearer use CLAT. A slightly pedantic note, if you have > a "dual > stack > APN" but the device only requests IPv6 then the device > will receive > an IPv6 bearer and requires CLAT. You will hear from > Ross and me > talking about having a single APN supporting all modes, > IPv4, IPv4v6 > and IPv6 bearers. There may be business reasons for > this, as well as > avoiding consumers having to change APNs. > > > In my understanding 464xlat/clat are trials these days. > They could > be improved before going live. If the 464xlat/clat happened > elsewhere than on the user terminal (e.g. BAse Station) I > think more > of these terminals could be accommodated, more business. > > > Hi, > > T-Mobile US's IPv6 deployment is 100% 464XLAT. > > According to measurements, 49% of connections to major internet > content > is over IPv6 from T-Mobile US > > http://www.worldipv6launch.__org/measurements/ > <http://www.worldipv6launch.org/measurements/> > > According to public statement, T-Mobile US has 50+ million > subscribers > in q3 2014 > > So, 49% of 50 Million -- i do not think it is fair to characterize > 464XLAT as only being a trial. > > > Hi Cameron, > > I am impressed by the figures, it's good for IPv6 in general. > > In other places 464xlat is still a trial. In these trials, my suggestion > is to not make CLAT mandatory on the device, and still offer native IPv4 > and native IPv6 to the end user. > > > Offering native IPv4 is not an option due to IPv4 address exhaustion. > > If this is realized (avoid CLAT), do you think T-Mobile subscribers > would talk easier to subscribers of these networks currently trialled? > > Or is it that subscribers of other networks MUST have CLAT in their > phones in order to talk to CLAT phones of T-Mobile? > > Alex > > > It is my recommendations that networks and service use IPv6 to avoid any > undue complications related to CGN / NAT44 / NAT64 / MAP and so on. > > IPv4 is fundamentally problematic in any network that exceeds 4 billion > nodes in size. Numerous networks are not that large. IPv4 deserves more consideration than what it seems to be implied above. T-Mobile is not the only network out there. If your goal is to present it as an example, I can agree with you - it's a good example, in one particular sense. Alex > I do not recommend using IPv4 on the Internet. > > Regards, > > Cameron > > > Regards, > > Cameron > > > > That means that the device vendors MUST implement CLAT > in the > smartphones which connect to a v6-only APN. It is a > too strong > requirement. > > [Heatley, Nick] Today's reality is that operators > cannot take > devices > to IPv6-only mode of operation without CLAT. In the > future will > other > alternatives appear? > > > Alternatives there are very many. > > E.g. 464lat/clat to run on an operator-controlled network > device, > not on end-user terminal. > > E.g. use a v4-APN and v6-in-v4 encapsulation on the > end-user device. > > 3GPP also designed a DS-MIPv6, not sure whether you are > aware of > it. It had the same goal of terminal on v6-only link. > > It's hard to justify requiring just one of them on all end-user > terminals because it will surely affect the other. > > It is easier for an end user to connect to a pure > v4-APN rather than > a v6 APN with CLAT. > > [Heatley, Nick] If they have the choice....when the > element of > choice > is taken away, the operator must make their network > bullet proof for > all devices supported. > > > Well, historic operators, MVNOs? > > Historic operators today no longer 'own' the device as in > the recent > past. Yes, they have contracts with well-funded > manufacturers, but > they also accept any other device to connect to their networks. > They sell SIM cards with DATA plans regardless of the device in > which this SIM card ends: they must offer unlocking codes > of all > devices they sell. Finally they must accept phone number > portability > for free. > > If this 464xlat/clat requirement is between a Historic > operator and > an MVNOs, then it may make sense. > > But one can not require the end-user to run CLAT translation. > > Alex > > > Internet-side initiated traffic would be an issue, > same as NAT44 > CGN. > > > YEs, I understand that reachability problem. > > But here we have a problem with requiring the end user > device to run > translation just because of IPv6. > > App writers have already solved the NAT44 reverse > reachability > problems - they work on non-CLAT devices behind NAT. > These apps > will > no longer work in the v6 world, if CLAT is not added. > > One would hardly migrate to IPv6 if too much translation is > required, > be it v4-v6 or v6-v4 translation. > > Compare this to the v6 migration in the DSL world: no > additional > CLAT > is required on end-user devices. > > Alex > > Nick > > -----Original Message----- From: Alexandru Petrescu > [mailto:alexandru.petrescu@ > <mailto:alexandru.petrescu@>__g__mail.com <http://gmail.com> > <mailto:alexandru.petrescu@__gmail.com > <mailto:alexandru.petrescu@gmail.com>>] Sent: 13 February > 2015 12:52 > To: Heatley, Nick; mohamed.boucadair@orange.com > <mailto:mohamed.boucadair@orange.com> > <mailto:mohamed.boucadair@__orange.com > <mailto:mohamed.boucadair@orange.com>> Cc: v6ops@ietf.org > <mailto:v6ops@ietf.org> > <mailto:v6ops@ietf.org <mailto:v6ops@ietf.org>> > Subject: Re: [v6ops] I-D Action: > draft-ietf-v6ops-mobile-____device-profile-17.txt - > C_REC#9 > > 464XLAT > > Le 13/02/2015 11:13, Heatley, Nick a écrit : > > A statement such as > > The device should only invoke the CLAT in the > absence of a the > IPv4 AF i.e. when the network does not > assign an > IPv4 cellular > address > > could be helpful? > > To go further, and define any additional > requirement, > then that > would be defining how an Operator could/should > manage their > remaining IPv4 public and private addressing. > This paper > should > only focus on the required device behaviour. > > As an aside 464xlat is a direct replacement for > the NAT44 > environments, typical in mobile operators with > large > consumer > bases. > > > Nick, > > Am I wrong to say that one can not ping 8.8.8.8 > from behind a > 464xlat, whereas one can ping 8.8.8.8 behind a nat44? > > If I am not wrong then 464xlat and nat44 are not really > equivalent. > > Alex > > Ideal if an operator is exhausting both public > and private > address space. If an operator has ample public > IPv4 and has > consumer products that are NAT44-free, then > they are in a > different place (a utopia). Nick > > > -----Original Message----- From: v6ops > [mailto:v6ops-bounces@ietf.org > <mailto:v6ops-bounces@ietf.org> > <mailto:v6ops-bounces@ietf.org > <mailto:v6ops-bounces@ietf.org>__>__] On Behalf Of > mohamed.boucadair@orange.com <mailto:mohamed.boucadair@orange.com> > <mailto:mohamed.boucadair@__orange.com > <mailto:mohamed.boucadair@orange.com>> Sent: 13 February > 2015 06:49 To: > Alexandru Petrescu Cc: v6ops@ietf.org > <mailto:v6ops@ietf.org> > <mailto:v6ops@ietf.org <mailto:v6ops@ietf.org>> > Subject: Re: [v6ops] I-D > Action: > draft-ietf-v6ops-mobile-____device-profile-17.txt > - C_REC#9 > 464XLAT > > Hi Alex, > > The intent of this reco is to address broken > IPv4-only > applications over an IPv6-only connectivity. > Ideally > applications > running on the device should be AF-independent. > > The draft relies on the IPv6 node requirements > RFC that > mandates > the supports of IPv6. Also, the I-D calls out > applications that > are provided by the vendor of the device: > > == APP_REC#2: Applications provided by the mobile > device vendor > must be independent of the underlying IP > address family. == > > Wouldn't this reco addresses your concern? > > Thank you. > > Cheers, Med > > -----Message d'origine----- De : v6ops > [mailto:v6ops-bounces@ietf.org > <mailto:v6ops-bounces@ietf.org> > <mailto:v6ops-bounces@ietf.org > <mailto:v6ops-bounces@ietf.org>__>__] De la part de > Alexandru Petrescu > Envoyé : jeudi 12 février 2015 17:27 À : > v6ops@ietf.org <mailto:v6ops@ietf.org> > <mailto:v6ops@ietf.org <mailto:v6ops@ietf.org>> > Objet : > Re: [v6ops] I-D Action: > draft-ietf-v6ops-mobile-____device-profile-17.txt - > > C_REC#9 464XLAT > > Hello, > > Thank you for this new version of the draft. > > I have a doubt with respect to the 464XLAT > requirement: > > C_REC#9: In order to ensure IPv4 service > continuity > in an > IPv6-only deployment context, the cellular > host should > implement the Customer Side Translator > (CLAT, [RFC6877]) > function which is compliant with > [RFC6052][RFC6145][RFC6146]. > > CLAT function in the cellular host allows > for IPv4-only > application and IPv4-referals to work on an > IPv6-only > connectivity. CLAT function requires a > NAT64 capability > [RFC6146] in the core network. > > The IPv4 Service Continuity Prefix used by > CLAT is > defined in > [RFC7335]. > > > I think this requirement leads to a situation > where the > network > operator deploys IPv6-native-only and IPv4 as > an add-on > partial > feature. > > On one hand, it is encouraging to see native > IPv6 and no > IPv4. > > On another hand, _partial_ IPv4 support is a > temptation > which > deceives in the end - it leads to turn off > IPv6 and > come back > to good ol' IPv4 and no IPv6. > > The 464XLAT is partial IPv4 support: does not > offer full > IPv4 > connectivity to the smartphone. It is not > possible to > address > the smartphone by its IPv4 address - DNS is > required; > this makes > it impossible to make a VPN tunnel, or Mobile > IP. One > can not a > deploy a wireless IPv4 router along the road in > a remote > area, > for example. > > This leads to a situation where the operator > requires > end user > to switch to another APN which is less IPv6. > > I think it is not a happy situation. > > I would suggest to qualify this requirement by > another > requirement. This initial requirement would > state that > _first_, > before any v4-v6 conversion mechanism is > considered, > both the > network and the end user MUST implement a > native IPv4 > stack and a > native IPv6 stack (not say 'dual' stack, which > is much > overloaded). > > We dont want to block IPv4 use when IPv6 arrives. > > Alex > > 12/02/2015 13:42, internet-drafts@ietf.org > <mailto:internet-drafts@ietf.org> > <mailto:internet-drafts@ietf.__org > <mailto:internet-drafts@ietf.org>> a écrit : > > > A New Internet-Draft is available from the > on-line > Internet-Drafts directories. This draft is > a work > item of the > IPv6 Operations Working Group of the IETF. > > Title : An Internet Protocol > Version 6 > (IPv6) Profile > for 3GPP Mobile Devices Authors : David > Binet Mohamed > Boucadair Ales Vizdal Gang Chen Nick > Heatley Ross > Chandler > Filename : > > draft-ietf-v6ops-mobile-____device-profile-17.txt Pages > : 18 Date : 2015-02-12 > > Abstract: This document defines a profile > that is a > superset of > that of the connection to IPv6 cellular > networks > defined in > the IPv6 for Third Generation Partnership > Project (3GPP) > Cellular Hosts document. This document > defines an > IPv6 profile > that a number of operators recommend in > order to > connect 3GPP > mobile devices to an IPv6-only or dual-stack > wireless network > (including 3GPP cellular network and IEEE > 802.11 > network) with > a special focus on IPv4 service continuity > features. > > Both hosts and devices with capability to share > their WAN (Wide > Area Network) connectivity are in scope. > > > The IETF datatracker status page for this > draft is: > https://datatracker.ietf.org/____doc/draft-ietf-v6ops-mobile-____device-prof > <https://datatracker.ietf.org/__doc/draft-ietf-v6ops-mobile-__device-prof> > > <https://datatracker.ietf.org/__doc/draft-ietf-v6ops-mobile-__device-prof > <https://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-prof>> > > > i > > l > > > e/ > > > There's also a htmlized version available at: > http://tools.ietf.org/html/____draft-ietf-v6ops-mobile-____device-profile-17 > <http://tools.ietf.org/html/__draft-ietf-v6ops-mobile-__device-profile-17> > > <http://tools.ietf.org/html/__draft-ietf-v6ops-mobile-__device-profile-17 > <http://tools.ietf.org/html/draft-ietf-v6ops-mobile-device-profile-17>> > > > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?____url2=draft-ietf-v6ops-mobile-____device-prof > <http://www.ietf.org/rfcdiff?__url2=draft-ietf-v6ops-mobile-__device-prof> > > <http://www.ietf.org/rfcdiff?__url2=draft-ietf-v6ops-mobile-__device-prof > <http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-mobile-device-prof>> > > > i > > l > > > e-17 > > > > Please note that it may take a couple of > minutes > from the time > of submission until the htmlized version > and diff > are available > at tools.ietf.org <http://tools.ietf.org> > <http://tools.ietf.org>. > > Internet-Drafts are also available by > anonymous FTP at: > ftp://ftp.ietf.org/internet-____drafts/ > <ftp://ftp.ietf.org/internet-__drafts/> > <ftp://ftp.ietf.org/internet-__drafts/ > <ftp://ftp.ietf.org/internet-drafts/>> > > > ___________________________________________________ > v6ops mailing > list v6ops@ietf.org <mailto:v6ops@ietf.org> > <mailto:v6ops@ietf.org <mailto:v6ops@ietf.org>> > https://www.ietf.org/mailman/____listinfo/v6ops > <https://www.ietf.org/mailman/__listinfo/v6ops> > > <https://www.ietf.org/mailman/__listinfo/v6ops > <https://www.ietf.org/mailman/listinfo/v6ops>> > > > > > > ___________________________________________________ v6ops > mailing > list v6ops@ietf.org <mailto:v6ops@ietf.org> > <mailto:v6ops@ietf.org <mailto:v6ops@ietf.org>> > https://www.ietf.org/mailman/____listinfo/v6ops > <https://www.ietf.org/mailman/__listinfo/v6ops> > <https://www.ietf.org/mailman/__listinfo/v6ops > <https://www.ietf.org/mailman/listinfo/v6ops>> > > > ___________________________________________________ v6ops > mailing > list v6ops@ietf.org <mailto:v6ops@ietf.org> > <mailto:v6ops@ietf.org <mailto:v6ops@ietf.org>> > https://www.ietf.org/mailman/____listinfo/v6ops > <https://www.ietf.org/mailman/__listinfo/v6ops> > > <https://www.ietf.org/mailman/__listinfo/v6ops > <https://www.ietf.org/mailman/listinfo/v6ops>> > > NOTICE AND DISCLAIMER This e-mail (including any > attachments) is > intended for the above-named person(s). If you > are not the > intended recipient, notify the sender immediately, > delete this > email from your system and do not disclose or > use for any > purpose. > > We may monitor all incoming and outgoing emails > in line with > current legislation. We have taken steps to > ensure that this > email and attachments are free from any virus, > but it > remains > your responsibility to ensure that viruses do > not adversely > affect you. > > EE Limited Registered in England and Wales Company > Registered > Number: 02382161 Registered Office Address: > Trident Place, > Mosquito Way, Hatfield, Hertfordshire, AL10 9BW. > > > > > NOTICE AND DISCLAIMER This e-mail (including any > attachments) is > intended for the above-named person(s). If you are > not the > intended recipient, notify the sender immediately, > delete this > email from your system and do not disclose or use > for any > purpose. > > We may monitor all incoming and outgoing emails in > line with > current legislation. We have taken steps to ensure > that this > email > and attachments are free from any virus, but it > remains your > responsibility to ensure that viruses do not adversely > affect you. > > EE Limited Registered in England and Wales Company > Registered > Number: 02382161 Registered Office Address: Trident > Place, > Mosquito > Way, Hatfield, Hertfordshire, AL10 9BW. > > > > > NOTICE AND DISCLAIMER This e-mail (including any > attachments) is > intended for the above-named person(s). If you are not > the intended > recipient, notify the sender immediately, delete this > email from > your > system and do not disclose or use for any purpose. > > We may monitor all incoming and outgoing emails in line > with current > legislation. We have taken steps to ensure that this > email and > attachments are free from any virus, but it remains your > responsibility to ensure that viruses do not adversely > affect you. > > EE Limited Registered in England and Wales Company > Registered > Number: > 02382161 Registered Office Address: Trident Place, > Mosquito Way, > Hatfield, Hertfordshire, AL10 9BW. > > > > ___________________________________________________ > v6ops mailing list > v6ops@ietf.org <mailto:v6ops@ietf.org> <mailto:v6ops@ietf.org > <mailto:v6ops@ietf.org>> > https://www.ietf.org/mailman/____listinfo/v6ops > <https://www.ietf.org/mailman/__listinfo/v6ops> > <https://www.ietf.org/mailman/__listinfo/v6ops > <https://www.ietf.org/mailman/listinfo/v6ops>> > > > > > --- L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast. http://www.avast.com
- [v6ops] I-D Action: draft-ietf-v6ops-mobile-devic… internet-drafts
- Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-d… Alexandru Petrescu
- Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-d… Ross Chandler
- Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-d… Lorenzo Colitti
- Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-d… mohamed.boucadair
- Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-d… Heatley, Nick
- Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-d… Alexandru Petrescu
- Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-d… Alexandru Petrescu
- Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-d… Alexandru Petrescu
- Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-d… mohamed.boucadair
- Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-d… Heatley, Nick
- Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-d… Alexandru Petrescu
- Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-d… Alexandru Petrescu
- Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-d… Heatley, Nick
- Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-d… mohamed.boucadair
- Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-d… Alexandru Petrescu
- Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-d… Alexandru Petrescu
- Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-d… Heatley, Nick
- Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-d… Ca By
- Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-d… Alexandru Petrescu
- Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-d… Alexandru Petrescu
- Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-d… Ca By
- Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-d… Ross Chandler
- Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-d… Metzler, Dan J
- Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-d… Gert Doering
- Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-d… Gert Doering
- Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-d… Alexandru Petrescu
- Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-d… Alexandru Petrescu
- Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-d… Alexandru Petrescu
- Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-d… Alexandru Petrescu
- Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-d… Erik Kline
- Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-d… mohamed.boucadair
- Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-d… Tore Anderson
- Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-d… Heatley, Nick
- Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-d… Kossut Tomasz - Hurt
- Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-d… Gert Doering
- Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-d… Alexandru Petrescu
- Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-d… Alexandru Petrescu
- Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-d… Tore Anderson
- Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-d… Alexandru Petrescu
- Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-d… Gert Doering
- Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-d… Alexandru Petrescu
- Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-d… Gert Doering
- Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-d… Alexandru Petrescu
- Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-d… mohamed.boucadair
- Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-d… Alexandru Petrescu
- Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-d… Kossut Tomasz - Hurt
- Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-d… Metzler, Dan J
- Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-d… Alexandru Petrescu
- Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-d… Alexandru Petrescu
- Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-d… Alexandru Petrescu
- Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-d… mohamed.boucadair
- Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-d… Alexandru Petrescu
- Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-d… jouni korhonen
- Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-d… Ross Chandler
- Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-d… Brian E Carpenter
- Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-d… jouni korhonen
- Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-d… Kossut Tomasz - Hurt
- Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-d… Ross Chandler
- Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-d… Alexandru Petrescu