Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT
Ca By <cb.list6@gmail.com> Fri, 13 February 2015 17:39 UTC
Return-Path: <cb.list6@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 EC58E1A006F for <v6ops@ietfa.amsl.com>; Fri, 13 Feb 2015 09:39:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level:
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 acy6AanVIN3X for <v6ops@ietfa.amsl.com>; Fri, 13 Feb 2015 09:38:59 -0800 (PST)
Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 222BC1A0060 for <v6ops@ietf.org>; Fri, 13 Feb 2015 09:37:37 -0800 (PST)
Received: by mail-we0-f172.google.com with SMTP id k48so18001489wev.3 for <v6ops@ietf.org>; Fri, 13 Feb 2015 09:37:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OjzEJC8tu5wgNDHR9YyX9L+3u1IPC7RDDz4jbBrVZlU=; b=U4VkRiec9k9QwhThDHUL7VnO9LDTIp/zdV64NaF3xat/WnrnsSZQhJdAcvIi3F3Uo9 fCCIy1q8hQTKLSWatIv2w5Yz1bBpnp3vl/Nc0Qw4y8PP9tE4jCoZY8N/ac+D4MorbAhi b1xdV/JqB67DzTaw6MyzzWLpil5mhhF8eAWfHPA8VJqVFNti55xZvJhzG/zCN/YR7gyk odJKm7lXU4aNTUtsBSYYqW88YbnVGnCG8wxpdEC01Mbf3omnKFx8z2fY0yVMvwdpAqrI 7xiTzSheK4S9/3Un1ieNxGYv1LNTFmrg42IvHj/8f9CcPYe1FmIRItxMP7P8x1ocAf1J UnoA==
MIME-Version: 1.0
X-Received: by 10.194.2.43 with SMTP id 11mr9390520wjr.104.1423849054222; Fri, 13 Feb 2015 09:37:34 -0800 (PST)
Received: by 10.216.107.198 with HTTP; Fri, 13 Feb 2015 09:37:34 -0800 (PST)
In-Reply-To: <54DE227D.9050303@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>
Date: Fri, 13 Feb 2015 09:37:34 -0800
Message-ID: <CAD6AjGRCvc314QaiGfMGLF2Wakn8ueQK55E-sxw3qW4FXLApOw@mail.gmail.com>
From: Ca By <cb.list6@gmail.com>
To: Alexandru Petrescu <alexandru.petrescu@gmail.com>
Content-Type: multipart/alternative; boundary="047d7b3a82b2173e8e050efbb1ac"
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/VkX_z5UfzU9owWHbs8dCkt3Y5uQ>
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: Fri, 13 Feb 2015 17:39:08 -0000
On Fri, Feb 13, 2015 at 8:12 AM, Alexandru Petrescu < alexandru.petrescu@gmail.com> wrote: > Le 13/02/2015 16:33, Heatley, Nick a écrit : > >> >> >> -----Original Message----- From: Alexandru Petrescu >> [mailto:alexandru.petrescu@gmail.com] Sent: 13 February 2015 14:35 >> To: Heatley, Nick; mohamed.boucadair@orange.com Cc: 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/ 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. 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@gmail.com] Sent: 13 February 2015 12:52 >>> To: Heatley, Nick; mohamed.boucadair@orange.com Cc: 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] On Behalf Of >>>> mohamed.boucadair@orange.com Sent: 13 February 2015 06:49 To: >>>> Alexandru Petrescu Cc: 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] De la part de Alexandru Petrescu >>>> Envoyé : jeudi 12 février 2015 17:27 À : 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 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 >>>>> >>>>> >>>>> i > >> l >>>>> >>>>> >>>>> e/ >>> >>>> >>>>> There's also a htmlized version available at: >>>>> 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 >>>>> >>>>> >>>>> 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. >>>>> >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>> >>>>> _______________________________________________ v6ops mailing >>>>> list v6ops@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/v6ops >>>>> >>>>> >>>>> >>>> >>>> _______________________________________________ v6ops mailing >>>> list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >>>> >>>> _______________________________________________ v6ops mailing >>>> list v6ops@ietf.org 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 > https://www.ietf.org/mailman/listinfo/v6ops >
- [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