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