Michel Gosse | 30 Jul 13:32 2014
Picon

V6 World 2015: CFP deadline extension

The fifth Edition of V6 World will take place in Paris from 17 to 18 March, 2015

The agenda will cover in particular SDN, Segment Routing/Spring, V6 in Data Centers and XLAT464 Deployments issues.

 

The call for proposals deadline has been extended to August 22, 2014.

 

More info: http://www.uppersideconferences.com/v6world2015/v6world2015cfp.html

 

 

 

_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops
Ross Chandler | 28 Jul 07:58 2014
Picon

draft-ietf-v6ops-ipv6-roaming-analysis-01


Hi All,
I’m very interested in and supportive of this draft and have gone through the draft and made updates for nits (spelling errors, minor suggested, wording changes etc) as per Fred’s last call. Hopefully, you’ll find these useful.

I work for eircom including the Mobile network of Meteor (in Ireland). We have begun the process of enabling IPv6 in our production network. At this stage we are limiting our plans to Android UEs that support 464xlat because of the possibility of encountering the issues mentioned in this draft.

Best regards,
Ross



The whole draft with my changes is below. There are too many to enumerate, suggest you diff it.




Network Working Group                                            G. Chen
Internet-Draft                                                   H. Deng
Intended status: Informational                              China Mobile
Expires: January 5, 2015                                      D. Michaud
                                                   Rogers Communications
                                                             J. Korhonen
                                                          Renesas Mobile
                                                            M. Boucadair
                                                          France Telecom
                                                               A. Vizdal
                                                     Deutsche Telekom AG
                                                            July 4, 2014


                     IPv6 Roaming Behavior Analysis
               draft-ietf-v6ops-ipv6-roaming-analysis-01

Abstract

   This document identifies a set of failure cases that may be encountered 
   by IPv6-enabled Mobile customers in roaming scenarios.  The failure
   causes include improper configuration, incomplete equipment 
   functionality or inconsistent IPv6 introduction strategy.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 5, 2015.

Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.





Chen, et al.             Expires January 5, 2015                [Page 1]


Internet-Draft            IPv6 Roaming Analysis                July 2014


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Roaming Architecture Description  . . . . . . . . . . . . . .   3
   3.  Roaming Scenario  . . . . . . . . . . . . . . . . . . . . . .   5
   4.  Failure Case in Attachment Stage  . . . . . . . . . . . . . .   6
   5.  Failure Cases in PDP/PDN Creation . . . . . . . . . . . . . .   7
     5.1.  Case 1: Splitting Dual-stack Bearer . . . . . . . . . . .   7
     5.2.  Case 2: Lack of IPv6 support in applications  . . . . . .   8
     5.3.  Case 3: Fallback Incapability . . . . . . . . . . . . . .   8
     5.4.  Case 4: 464xlat Support . . . . . . . . . . . . . . . . .   9
   6.  Discussions . . . . . . . . . . . . . . . . . . . . . . . . .   9
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  10
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  11
     10.2.  Informative References . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

   Many Mobile operators either have already deployed IPv6 or are in a
   pre-deployment stage of supporting IPv6 in their production networks.
   A customer in such a network can be provided IPv6 connectivity if 
   their User Equipment (UE) is IPv6-compliant. A detailed overview of 
   IPv6 support in 3GPP architectures is provided in [RFC6459]. 
   Operators may adopt various approaches to deploy IPv6 in mobile 
   networks, for example the solutions described in [TR23.975]. 
   Depending on network conditions either dual-stack or single-stack 
   IPv6 is selected.

   In production networks it has been observed that a mobile subscriber
   roaming around a different operator’s areas may experience service 
   degradations or interruptions due to inconsistent configurations and 
   incomplete functionality of equipment in the network.

   This memo intends to document the observed failed cases and analyze
   the causes.




Chen, et al.             Expires January 5, 2015                [Page 2]


Internet-Draft            IPv6 Roaming Analysis                July 2014


2.  Roaming Architecture Description

   The roaming process occurs in the following scenarios:

   o  International roaming: a mobile UE enters a visited network,
      where a different Public Land Mobile Network (PLMN) identity is
      used.  The UE could, either in an automatic mode or a manual mode,
      attach to the visited PLMN.

   o  Intra-PLMN mobility: a mobile UE moves to a different area of the
      Home Public Land Mobile Network (HPLMN).  However, the
      subscriber profile may not be stored in the area. To allow network 
      attachment the subscribers profile needs to be downloaded from the 
      home network area.

   When a UE is turned on or is transferred via a handover to a visited
   network, the mobile device will scan all radio channels and find
   available Public Land Mobile Networks (PLMNs) to attach to. The 
   Serving GPRS Support Node (SGSN) or the Mobility Management Entity (MME)
   in the visited networks must contact the Home Location Register(HLR) or 
   Home Subscriber Server(HSS) and obtain the subscriber profile.  After
   the authentication and registration process is completed, the Packet Data
   Protocol (PDP) or Packet Data Networks (PDN) activation and traffic
   flows may be operated differently according to the subscriber profile
   stored in HLR or HSS.  Two modes are shown in the figure to illustrate, 
   these are “Home routed traffic” (Figure 1) and “Local breakout" 
   (Figure 2).

+---------------------------------+             +------------------------+
|Visited Network                  |             |Home Network            |
|  +----+           +--------+    |             |    +--------+ Traffic Flow
|  | UE |==========>|SGSN/MME|======================>|GGSN/PGW|============>
|  +----+           +--------+    | Signaling   |    +--------+          |
|                        |-------------------------->+--------+          |
|                                 |             |    |HLR/HSS |          |
|                                 |             |    +--------+          |
+---------------------------------+             +------------------------+

                       Figure 1: Home Routed Traffic












Chen, et al.             Expires January 5, 2015                [Page 3]


Internet-Draft            IPv6 Roaming Analysis                July 2014


+---------------------------------+             +------------------------+
|Visited Network                  |             |Home Network            |
|  +----+           +--------+    | Signaling   |    +--------+          |
|  | UE |==========>|SGSN/MME|---------------------->|HLR/HSS |          |
|  +----+           +--------+    |             |    +--------+          |
|                       ||        |             |                        |
|                   +--------+    |             |                        |
|                   |GGSN/PGW|    |             |                        |
|                   +--------+    |             |                        |
|         Traffic Flow  ||        |             |                        |
+-----------------------||--------+             +------------------------+
                        \/

                         Figure 2: Local Breakout

   In the home routed mode, the subscriber's UE activates the PDP/PDN 
   context and get an address from the home network. All traffic is routed 
   back to the home network.  This is likely to be the case international 
   roaming of Internet data services to facilitate the charging process 
   between the two operators concerned.

   In the local breakout mode, the subscriber address is assigned by the 
   visited network.  The traffic flow is offloaded locally at a network 
   node close to that device's point of attachment in the visited network.  
   Therefore, a more efficient route to the data service is achieved. The 
   international roaming of IP Multimedia Subsystem (IMS) based services, 
   e.g.  Voice over LTE (VoLTE)[IR.92] , is claimed to select the local 
   breakout mode in [IR.65].  Data service roaming across different areas
   within a operator network could use local breakout mode in order to get
   more efficient traffic routing.  The local breakout mode could be also 
   applied to an operators alliance for international roaming of data 
   service. EU Roaming Regulation III [EU-Roaming-III] involves local 
   breakout mode for European subscribers roaming in European 2G/3G 
   networks to choose to have their Internet data routed directly to the 
   Internet from their current VPLMN. The following enumerates the more 
   specific configuration considerations.

   o  Operators may add the APN-OI-Replacement flag defined in 3GPP
      [TS29.272] into user's subscription-data.  The visited network
      indicates a local domain name to replace the user requested Access
      Point Name (APN).  Consequently, the traffic would be steered to the 
      visited network.  Those functions are normally deployed for the 
      Intra-PLMN mobility cases.

   o  Operators may also configure the VPLMN-Dynamic-Address-Allowed
      flag [TS29.272] in the user profile to enable local breakout mode
      in a Visited Public Land Mobile Network (VPLMN).



Chen, et al.             Expires January 5, 2015                [Page 4]


Internet-Draft            IPv6 Roaming Analysis                July 2014


   o  3GPP specified Selected IP Traffic Offload (SIPTO)
      function [TS23.401] since Release 10 in order to get efficient
      route paths.  It enables an operator to offload certain types of
      traffic at a network node close to that device's point of
      attachment to the access network.

   o  GSMA has defined RAVEL [IR.65] as the IMS international roaming
      architecture.  Local breakout mode has been adopted for the IMS
      roaming architecture.

3.  Roaming Scenario

   Two stages occur when a subscriber roams to a visited network and 
   intends to start data services.

   o  Nework attachment: this occurs when the subscriber enters a
      visited network.  During an attachment, the visited network should
      authenticate the subsriber and make a location update to the 
      HSS/HLR in the home network of the subsriber.  Accordingly, the 
      subscriber profile is offered from the HSS/HLR.  The subscriber 
      profile contains the allowed Access Point Names (APN), the allowed
      PDP/PDN Types and rules regarding the routing of data sessions 
      (i.e. home routed or local breakout mode) [TS29.272]. The SGSN/MME
      in the visited network can use this information to facilitate the
      subsequent PDP/PDN session creation.

   o  PDP/PDN context creation: this occurs after the subsriber makes
      a sucessful attachment.  It is worth nothing that this stage is
      integrated with the attachment stage in the case of 4G, but a
      seperated process with 2/3G. 3GPP specifies three types of Packet
      Data Protocol (PDP)/Packet Data Networks (PDN) to describe
      connections, i.e. PDP/PDN Type IPv4, PDP/PDN Type IPv6 and PDP/
      PDN Type IPv4v6.  When a subscriber creates a data session their
      device requests a particular PDP/PDN Type. The allowed PDP/PDN 
      types for that subscriber are learned from the attachment stage. 
      If their subscription profile allows it the SGSN/MME may initiate
      a PDP/PDN request to the GGSN/PGW.

   The failures are likely to occur in both stages due to an incompliant
   implementation in the visited network or a mismatch between the 
   subscriber requested and the capability of the visited network. The 
   failures in the attachment stage are independent of the home routed or 
   the local breakout mode, while most failure cases in the PDP/PDN 
   context creation stage occur in the local breakout cases. Section 4 
   and 5 describe each case. The below table lists several cases 
   concerning the the PDP/PDN creation stage.




Chen, et al.             Expires January 5, 2015                [Page 5]


Internet-Draft            IPv6 Roaming Analysis                July 2014


   +-------------+-------------------+--------------+
   | UE request  |  PDN/PDP IP Type  |Local breakout|
   |             |     permitted     |              |
   +-------------+-------------------+--------------+
   | IPv4v6      |  IPv4 or IPv6     |Failure case 1|
   +-------------+-------------------+--------------+
   | IPv4v6      |      IPv6         |Failure case 2|
   +-------------+-------------------+--------------+
   | IPv6        |      IPv4         |Failure case 3|
   +-------------+-------------------+--------------+
   | IPv6        |       IPv6        |Failure case 4|
   | with 464xlat|   without NAT64   |              |
   +-------------+-------------------+--------------+

                  Table 1: Roaming Scenario Descriptions

4.  Failure Case in Attachment Stage

   3GPP specified PDP/PDN type IPv4v6 in order to allow a UE request
   both IPv4 and IPv6 within a single PDP/PDN request.  This option is
   stored as a part of subscription data for a subscriber in the HLR/
   HSS. PDP/PDN type IPv4v6 was introduced at the inception of
   Evolved Packet System (EPS) in 4G networks.  The nodes in 4G networks
   should have no issues with the handling of this PDN type.  However,
   support varies in 2/3G networks denpending on Serving GPRS
   Support Node (SGSN) software version.  In theory the S4-SGSN (i.e.
   an SGSN with a S4 interface) supports the PDP/PDN type IPv4v6 since
   Release 8 and a Gn-SGSN (i.e., the SGSN with Gn interface) supports it
   since Release 9.  In most cases, operators normally use Gn-SGSN to
   connect either GGSN in 3G or Packet Data Network Gateway (PGW) in 4G.
   The MAP (Mobile Application Part) protocol, as defined in 3GPP
   [TS29.002], is used over the Gr interface between SGSN and HLR.  The
   MAP Information Element (IE) "ext-pdp-Type" contains the IPv4v6 PDP
   Type that is conveyed to SGSN from the HLR within the Insert 
   Subscriber Data (ISD) MAP operation.  If the SGSN does not support 
   the IPv4v6 PDP Type, it will not support the "ext-pdp-Type" IE and 
   consequently it must silently discard that IE and continue processing 
   the rest of the ISD MAP message. The issue we observe is that multiple
   SGSNs will be unable to correctly process a subscriber's data received 
   in the Insert Subscriber Data procedure[TS23.060]. As a consequence,
   it will likely refuse the subscriber attach request. This is erroneous
   behaviour due to the equipment not being 3GPP Release 9 compliant.

   Operators may have to remove the PDP/PDN type IPv4v6 from the  HLR/HSS 
   in the home network, that will restrict UEs to only initiate IPv4 PDP 
   or IPv6 PDP activation.  In order to avoid this situation, operators
   should make a comprehensive roaming agreement to support IPv6 and
   ensure that it aligns with the GSMA documents, e.g [IR.33], [IR.88]



Chen, et al.             Expires January 5, 2015                [Page 6]


Internet-Draft            IPv6 Roaming Analysis                July 2014


   and [IR.21].  Such an agreement requires the visited operator to get 
   the necessary patch on all their SGSN nodes to support PDP/PDN type 
   IPv4v6.

   As an alternative solution there are some specific implementations 
   (not standardised by 3GPP) in the HLS/HSS of the home network.
   When the HLR/HSS receives an Update Location message from a visited 
   SGSN known to not support the PDP type IPv4v6, subscription data with
   only PDP/PDN type IPv4 will be sent to that SGSN in the Insert 
   Subscriber Data procedure.  It guarantees the user profile is 
   compatible with visited SGSN/MME capability.

5.  Failure Cases in PDP/PDN Creation

   When a subscriber succeeds in the attach stage, the IP allocation 
   process takes place to allocate IP addresses to the subscriber.  This
   section summarizes several failures in the break-out cases.

5.1.  Case 1: Splitting Dual-stack Bearer

   Dual-stack capability can be provided using separate PDP/PDN
   activations.  That means only separate parallel single-stack IPv4 
   and IPv6 PDP/PDN connections are allowed to be initiated to separately
   allocate IPv4 and IPv6 addresses.
   The cases are listed below:

   o  The SGSN/MME returns Session Manamgement (SM) Cause #52, "Single
      address bearers only allowed", or SM Cause #28 "Unknown PDP
      address or PDP type" as per[TS24.008] and [TS24.301].

   o  The SGSN/MME does not set the Dual Address Bearer Flag because the
      operator uses single addressing per bearer to support interworking 
      with nodes of earlier releases

   A roaming subscriber's UE with IPv4v6 PDP/PDN type has to change the
   request into two separated PDP/PDN requests with a single IP version in
   order to achieve equivalent results. 
   Some drawbacks of this case are listed below:

   o  The parallel PDP/PDN activations would likely double PDP/PDN
      resources consumption.  It also impacts the capacity of GGSN/PGW,
      since a certain amount of PDP/PDN activations are only allowed on
      those nodes.

   o  Some networks may only allow one PDP/PDN is alive for each
      subscriber.  For example, an IPv6 PDP/PDN will be rejected if the
      subscriber has an active IPv4 PDP/PDN.  Therefore, the subscriber
      will lose the IPv6 connection in the visited network.  It is even 
      worse as they may have a risk of losing all data connectivity if the
      IPv6 PDP gets rejected with a permanent error at the APN-level and
      not specific to the PDP-Type IPv6 requested.


Chen, et al.             Expires January 5, 2015                [Page 7]


Internet-Draft            IPv6 Roaming Analysis                July 2014


   o  Additional correlations between those two PDP/PDN contexts are
      required on the charging system.

   o  Policy and Charging Rules Function(PCRF)/Policy and Charging
      Enforcement Function (PCEF) treats the IPv4 and IPv6 session as
      independent and performs different Quality of Service (QoS)
      policies.  The subscriber may have unstable experiences due to
      different behaviors on each IP version connection.

   o  Mobile devices may have a limitation on allowed simultaneous
      PDP/PDN activations.  Too many active PDP/PDN connections may result in
      other unrelated services broken.

   Operators may have to disable the local-break mode to avoid the
   risks.  Another approach is to set a dedicated Access Point Name
   (APN) profile to only request PDP/PDN type IPv4 in the roaming
   network.

5.2.  Case 2: Lack of IPv6 support in applications

   Some operators may adopt an IPv6-only configuration for the IMS service,
   e.g.  Voice over LTE (VoLTE)[IR.92] or Rich Communication Suite
   (RCS)[RCC.07].  Since the IMS roaming architecture will offload all
   traffic in the visited network, a dual-stack subscriber can only be
   assigned with an IPv6 prefix and no IPv4 address returned. This 
   requires that all the IMS based applications should be IPv6 capable. 
   A translation-based method, for example Bump-in-the-host (BIH)[RFC6535]
   or 464xlat [RFC6877] may help to address the issue if there are IPv6
   compatibility problems.  Those functions could be automatically
   enabled in an IPv6-only network and disabled in a dual-stack or IPv4
   network.

5.3.  Case 3: Fallback Incapability

   3GPP specified the PDP/PDN type IPv6 as early as PDP/PDN type IPv4.
   Therefore, the IPv6 single PDP/PDN type has been well supported and
   interpretable in the 3GPP network nodes.  Roaming to IPv4-only
   networks and making a IPv6 PDP/PDN request should guarantee that the 
   subscription data is compatible with the visited pre-Release 9 SGSN.
   When a subscriber requests PDP/PDN type IPv6, the network should only 
   return the expected IPv6 prefix.  The mobile device may fail to get
   an IPv6 prefix if the visited network can only allocate an IPv4 address 
   to the subscriber.  In that case, the request will be dropped and the 
   cause code should be sent to the user.

   A proper fallback is desirable, however the behavior is implementation
   specific.  There are some mobile devices have the ability to provide
   a different configuration for home network and visited network



Chen, et al.             Expires January 5, 2015                [Page 8]


Internet-Draft            IPv6 Roaming Analysis                July 2014


   respectively.  For instance, the Android system solves the issue by 
   setting the roaming protocol to IPv4 for the Access Point Name(APN). 
   It guarantees that UE will always initiate an PDP/PDN of type IPv4 in 
   the roaming area.

5.4.  Case 4: 464xlat Support

   464xlat[RFC6877] is proposed to address the IPv4 compatibility issue 
   in a IPv6 single-stack environment.  The function on a mobile device
   is likely in conjunction with a PDP/PDN IPv6 type request and requires 
   a remote NAT64 [RFC6146] gateway. 464xlat may use the mechanism 
   defined in [RFC7050] to automatically detect the presence of DNS64 and
   to learn the IPv6 prefix used for protocol translation. In the local
   breakout approach when a mobile device roams to an IPv6 visited network
   without the presence of NAT64 or DNS64, 464xlat will fail to function. 
  
   The issue has been found mostly in a intra-PLMN mobility case for the
   time being.  Considering the various network's situations, operators
   may turn off the local breakout and use the home routed mode to perform
   464xlat.  Some devices may support the configuration to adopt 464xlat
   in the home networks and use IPv4-only in the visited networks with
   different roaming profile configurations.  This could also be a
   solution to address this issue.

6.  Discussions

   Several failure cases have been discussed in this document.  It has
   been testified that the major issues happened at two stages, i.e.,
   the initial network attach and the IP allocation process.

   During the initial network attach, PDP/PDN type IPv4v6 is the major
   problem to the visited pre-Release 9 SGSN.  The dual-stack deployment
   is recommended in most cases.  However, it may take some times in a
   mobile environment. 3GPP didn't specify PDP/PDN type IPv4v6 in the
   early release.  Such PDP/PDN type is supported in new-built EPS
   network, but didn't support well in the third generation network.
   The situations discussed may cause the roaming issues dropping with
   the attach request from dual-stack subscribers.  Operators may have to adopt
   temporary solution unless all the interworking nodes(i.e. the SSGNs) in
   the visited network have been upgraded to support the ext-PDP-Type
   feature.

   The issues in the IP address allocation process are caused by a local
   breakout policy.  Since the IP address is allocated by the visited 
   GGSN or PGW, the mismatch is found in the following aspects.

   o  The mismatch between the requested PDP/PDN type and the permitted 
      PDP/PDN type



Chen, et al.             Expires January 5, 2015                [Page 9]


Internet-Draft            IPv6 Roaming Analysis                July 2014


   o  The mismatch between the application capability and allowed network
      connections

   o  The mismatch between mobile device function (e.g., 464xlat) and
      the support for that function in the vistited network

   There are some solutions to overcome the issue.  Those solutions can
   be made either in the network side or mobile device side.  The below
   lists potential workarounds.

   o  Change local breakout to the home routed mode

   o  A dedicated roaming APN profile is implemented for the roamer. When a
      subscriber roams to a visited network, PDP/PDN type IPv4 is to be 
      always selected for session activation.

   o  Networks could deploy a AAA server to coordinate the mobile device
      capability.  Once the GGSN/PGW receives the session creation
      request, it will initiate an Access-Request to an AAA server in
      the home network via the Radius protocol.  The Access-Request
      contains subscriber and visited network information, e.g.  PDP/PDN
      Type, International Mobile Equipment Id (IMEI), Software
      Version(SV) and visited SGSN/MME location code, etc.  The AAA
      server could take mobile device capability and combine it with the
      visited network information to ultimately determine the type of
      session to be created, i.e.  IPv4, IPv6 or IPv4v6.

7.  IANA Considerations

   This document makes no request of IANA.

8.  Security Considerations

   This document does not define a new architecture nor a new
   protocol, but it is encouraged to refer to [RFC6459] for a generic
   discussion on IPv6-related security considerations.

9.  Acknowledgements

   Many thanks to F.  Baker and J.  Brzozowski for their support.

   This document is the result of the IETF v6ops IPv6-Roaming design
   team effort.

   The authors would like to thank Mikael Abrahamsson, Victor Kuarsingh,
   Heatley Nick, Alexandru Petrescu, Tore Anderson and Cameron Byrne for
   their helpful comments.




Chen, et al.             Expires January 5, 2015               [Page 10]


Internet-Draft            IPv6 Roaming Analysis                July 2014


10.  References

10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC6052]  Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
              Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
              October 2010.

   [RFC6146]  Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
              NAT64: Network Address and Protocol Translation from IPv6
              Clients to IPv4 Servers", RFC 6146, April 2011.

   [RFC6147]  Bagnulo, M., Sullivan, A., Matthews, P., and I. van
              Beijnum, "DNS64: DNS Extensions for Network Address
              Translation from IPv6 Clients to IPv4 Servers", RFC 6147,
              April 2011.

   [RFC6535]  Huang, B., Deng, H., and T. Savolainen, "Dual-Stack Hosts
              Using "Bump-in-the-Host" (BIH)", RFC 6535, February 2012.

   [RFC6877]  Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
              Combination of Stateful and Stateless Translation", RFC
              6877, April 2013.

   [RFC7050]  Savolainen, T., Korhonen, J., and D. Wing, "Discovery of
              the IPv6 Prefix Used for IPv6 Address Synthesis", RFC
              7050, November 2013.

10.2.  Informative References

   [EU-Roaming-III]
              "http://www.amdocs.com/Products/Revenue-
              Management/Documents/
              amdocs-eu-roaming-regulation-III-solution.pdf", July 2013.

   [IR.21]    Global System for Mobile Communications Association,
              GSMA., "Roaming Database, Structure and Updating
              Procedures", July 2012.

   [IR.33]    Global System for Mobile Communications Association,
              GSMA., "GPRS Roaming Guidelines", July 2012.

   [IR.65]    Global System for Mobile Communications Association,
              GSMA., "IMS Roaming & Interworking Guidelines", May 2012.




Chen, et al.             Expires January 5, 2015               [Page 11]


Internet-Draft            IPv6 Roaming Analysis                July 2014


   [IR.88]    Global System for Mobile Communications Association,
              GSMA., "LTE Roaming Guidelines", January 2012.

   [IR.92]    Global System for Mobile Communications Association
              (GSMA), , "IMS Profile for Voice and SMS Version 7.0",
              March 2013.

   [RCC.07]   Global System for Mobile Communications Association
              (GSMA), , "Rich Communication Suite 5.1 Advanced
              Communications Services and Client Specification Version
              4.0", November 2013.

   [RFC6459]  Korhonen, J., Soininen, J., Patil, B., Savolainen, T.,
              Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation
              Partnership Project (3GPP) Evolved Packet System (EPS)",
              RFC 6459, January 2012.

   [RFC6586]  Arkko, J. and A. Keranen, "Experiences from an IPv6-Only
              Network", RFC 6586, April 2012.

   [TR23.975]
              3rd Generation Partnership Project, 3GPP., "IPv6 migration
              guidelines", June 2011.

   [TS23.060]
              3rd Generation Partnership Project, 3GPP., "General Packet
              Radio Service (GPRS); Service description; Stage 2 v9.00",
              March 2009.

   [TS23.401]
              3rd Generation Partnership Project, 3GPP., "General Packet
              Radio Service (GPRS) enhancements for Evolved Universal
              Terrestrial Radio Access Network (E-UTRAN) access v9.00",
              March 2009.

   [TS24.008]
              3rd Generation Partnership Project, 3GPP., "Mobile radio
              interface Layer 3 specification; Core network protocols;
              Stage 3 v9.00", September 2009.

   [TS24.301]
              3rd Generation Partnership Project, 3GPP., "Non-Access-
              Stratum (NAS) protocol for Evolved Packet System (EPS) ;
              Stage 3 v9.00", September 2009.







Chen, et al.             Expires January 5, 2015               [Page 12]


Internet-Draft            IPv6 Roaming Analysis                July 2014


   [TS29.002]
              3rd Generation Partnership Project, 3GPP., "Mobile
              Application Part (MAP) specification v9.00", December
              2009.

   [TS29.272]
              3rd Generation Partnership Project, 3GPP., "Mobility
              Management Entity (MME) and Serving GPRS Support Node
              (SGSN) related interfaces based on Diameter protocol
              v9.00", September 2009.

Authors' Addresses

   Gang Chen
   China Mobile
   53A,Xibianmennei Ave.,
   Xuanwu District,
   Beijing  100053
   China

   Email: phdgang-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org


   Hui Deng
   China Mobile
   53A,Xibianmennei Ave.,
   Xuanwu District,
   Beijing  100053
   China

   Email: denghui-5+5aOzUXOJconNqTyK5kxQ@public.gmane.org


   Dave Michaud
   Rogers Communications
   8200 Dixie Rd.
   Brampton, ON L6T 0C1
   Canada

   Email: dave.michaud-w6+5gY1eu51YzD5mSbZInQ@public.gmane.org


   Jouni Korhonen
   Renesas Mobile
   Porkkalankatu 24
   FIN-00180 Helsinki, Finland

   Email: jouni.nospam-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org



Chen, et al.             Expires January 5, 2015               [Page 13]


Internet-Draft            IPv6 Roaming Analysis                July 2014


   Mohamed Boucadair
   France Telecom
   Rennes,
   35000
   France

   Email: mohamed.boucadair-C0LM0jrOve7QT0dZR+AlfA@public.gmane.org


   Vizdal Ales
   Deutsche Telekom AG
   Tomickova 2144/1
   Prague 4,  149 00
   Czech Republic

   Email: ales.vizdal-jxcAKmg0X+HtwjQa/ONI9g@public.gmane.org



































Chen, et al.             Expires January 5, 2015               [Page 14]
_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops
fred | 27 Jul 20:00 2014
Picon

draft-ietf-v6ops-ipv6-roaming-analysis WGLC

This is to initiate a two week working group last call of
http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-roaming-analysis.  
Please read it now. If you find nits (spelling errors, minor suggested
wording changes, etc), comment to the authors; if you find greater
issues, such as disagreeing with a statement or finding additional
issues that need to be addressed, please post your comments to the
list.

We are looking specifically for comments on the importance of the
document as well as its content. If you have read the document and
believe it to be of operational utility, that is also an important
comment to make.

_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops

Aijun Wang | 23 Jul 07:35 2014
Picon

Re: Comments on draft-wang-v6ops-flow-label-refelction-01

Hi, Brain:

Thanks for your comments. Below is my opinion to your concern points.
1. If some session support reflection, and others not, then the unsupported
session will be less likely recognized and controlled, there is no other
side-effect. Packets in bi-direction will be load balanced according to the
RFC6438, regardless whether the IPv6 flow label is reflected or not.
2.The reason that the IPv6 flow label is not supported in the real world is
that we have not find some killer-application that can exploit this field.
The mechanism of IPv6 flow label reflection can increase the opportunities
of such killer-application be hatched, not the contrary.
3. For mechanism of IPv6 flow label reflection, we strongly recommend this
value be manipulated only at the IPv6 packet endpoints, not the in-path
device. What is the motion for firewalls to rewrite this value?
4.The session for flow label can be UDP request/reply or TCP request/reply.
If one same client have multiple Http connections, there will be multiple
distinctive IPv6 Flow label. That is to say, this value is unique in the
local host for every TCP/UDP session.
5.For In-path device, it needs actually 3-tuple {Flow Label, Source Addr,
Destination Addr} to identify the unique session. If the flow label be
reflected, then the same 3-tuple can used to identify bi-direction traffic
of this session, or else it needs two different 3-tuple, or to parse the
extend IPv6 header.
6. Considering on-path attack, I think we can view this value as one magic
number, which is widely used in various application protocol. This magic
number/IPv6 flow label will be used only to coordinate the bi-direction
traffic of one session. If it is changed by some on-path attacker, it only
influence the recognition accuracy and control of the session. For
differentiated service based on this value, we need other mechanism to
protect or authenticate it. It is same risk for differentiated services that
based on DSCP value.
7. The IPv6 flow label field is unique in IPv6 packet, we should propose to
exploit its potential value actively. From the viewpoint of application
developer, there is no more differences between IPv6 packet and IPv4 packet
except this field and the length of IP address. The little change of host
operation system will be more influence to the IPv6 application and the
service that based on IPv6. This change can be deployed incrementally.

Best Regards.

-----Original Message-----
From: v6ops [mailto:v6ops-bounces@...] On Behalf Of Brian E Carpenter
Sent: Wednesday, July 23, 2014 3:14 AM
To: IPv6 Operations
Subject: [v6ops] Comments on draft-wang-v6ops-flow-label-refelction-01

There wasn't time for me to line up at the microphone, so here are my
comments. I think the idea is quite interesting, but a little optimistic.

What are the effects of some sessions supporting reflection and others not?
We know very well that even the basic RFC 6437 flow label is not supported
yet in the real world, so widespread use of reflection is years in the
future.

There's no discussion of flow label rewriting by firewalls, which we know
from the 6man discussions before RFC 6437 is a real issue. If the scope is
strictly limited to a single administrative domain, that's OK, but the
general end-to-end case probably fails.

Actually, the draft doesn't clarify exactly what is a session for flow label
purposes. As noted in the meeting, is a "stateless"
session (UDP request/reply) a session for this purpose? What about multiple
HTTP connections from the same client?

The uniqueness rule for flow labels is that a flow is identified by the
3-tuple {Flow Label, Source Addr, Destination Addr}. The flow label value
itself might not be unique in the intermediate nodes, so any state must be
keyed by the 3-tuple, with the two addresses either way round.

The mechanism seems very exposed to on-path attacks, since an attacker could
forge a reverse packet with the correct label, even before the first TCP
ACK. So nobody should rely on the flow label alone for anything important.
(I don't think there is any new risk for off-path attacks.)

Finally I think the document would have more chance of success if it was
made Informational, without that SHOULD. Just describe this as a use case
for the flow label - it is completely consistent with RFC 6437. If the
original label is pseudo-random, it will do fine as a reflected label from
the other node.

Regards
   Brian

_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops

_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops

Aijun Wang | 23 Jul 07:40 2014
Picon

Re: Comments on draft-wang-v6ops-flow-label-refelction-01

Hi, Brain:

Thanks for your comments. Below is my opinion to your concern points.
1. If some session support reflection, and others not, then the unsupported
session will be less likely recognized and controlled, there is no other
side-effect. Packets in bi-direction will be load balanced according to the
RFC6438, regardless whether the IPv6 flow label is reflected or not.
2.The reason that the IPv6 flow label is not supported in the real world is
that we have not find some killer-application that can exploit this field.
The mechanism of IPv6 flow label reflection can increase the opportunities
of such killer-application be hatched, not the contrary.
3. For mechanism of IPv6 flow label reflection, we strongly recommend this
value be manipulated only at the IPv6 packet endpoints, not the in-path
device. What is the motion for firewalls to rewrite this value?
4.The session for flow label can be UDP request/reply or TCP request/reply.
If one same client have multiple Http connections, there will be multiple
distinctive IPv6 Flow label. That is to say, this value is unique in the
local host for every TCP/UDP session.
5.For In-path device, it needs actually 3-tuple {Flow Label, Source Addr,
Destination Addr} to identify the unique session. If the flow label be
reflected, then the same 3-tuple can used to identify bi-direction traffic
of this session, or else it needs two different 3-tuple, or to parse the
extend IPv6 header.
6. Considering on-path attack, I think we can view this value as one magic
number, which is widely used in various application protocol. This magic
number/IPv6 flow label will be used only to coordinate the bi-direction
traffic of one session. If it is changed by some on-path attacker, it only
influence the recognition accuracy and control of the session. For
differentiated service based on this value, we need other mechanism to
protect or authenticate it. It is same risk for differentiated services that
based on DSCP value.
7. The IPv6 flow label field is unique in IPv6 packet, we should propose to
exploit its potential value actively. From the viewpoint of application
developer, there is no more differences between IPv6 packet and IPv4 packet
except this field and the length of IP address. The little change of host
operation system will be more influence to the IPv6 application and the
service that based on IPv6. This change can be deployed incrementally.

Best Regards.

-----Original Message-----
From: v6ops [mailto:v6ops-bounces@...] On Behalf Of Brian E Carpenter
Sent: Wednesday, July 23, 2014 3:14 AM
To: IPv6 Operations
Subject: [v6ops] Comments on draft-wang-v6ops-flow-label-refelction-01

There wasn't time for me to line up at the microphone, so here are my
comments. I think the idea is quite interesting, but a little optimistic.

What are the effects of some sessions supporting reflection and others not?
We know very well that even the basic RFC 6437 flow label is not supported
yet in the real world, so widespread use of reflection is years in the
future.

There's no discussion of flow label rewriting by firewalls, which we know
from the 6man discussions before RFC 6437 is a real issue. If the scope is
strictly limited to a single administrative domain, that's OK, but the
general end-to-end case probably fails.

Actually, the draft doesn't clarify exactly what is a session for flow label
purposes. As noted in the meeting, is a "stateless"
session (UDP request/reply) a session for this purpose? What about multiple
HTTP connections from the same client?

The uniqueness rule for flow labels is that a flow is identified by the
3-tuple {Flow Label, Source Addr, Destination Addr}. The flow label value
itself might not be unique in the intermediate nodes, so any state must be
keyed by the 3-tuple, with the two addresses either way round.

The mechanism seems very exposed to on-path attacks, since an attacker could
forge a reverse packet with the correct label, even before the first TCP
ACK. So nobody should rely on the flow label alone for anything important.
(I don't think there is any new risk for off-path attacks.)

Finally I think the document would have more chance of success if it was
made Informational, without that SHOULD. Just describe this as a use case
for the flow label - it is completely consistent with RFC 6437. If the
original label is pseudo-random, it will do fine as a reflected label from
the other node.

Regards
   Brian

_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops

_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops

Brian E Carpenter | 22 Jul 21:13 2014
Picon

Comments on draft-wang-v6ops-flow-label-refelction-01

There wasn't time for me to line up at the microphone, so
here are my comments. I think the idea is quite interesting,
but a little optimistic.

What are the effects of some sessions supporting reflection
and others not? We know very well that even the basic RFC 6437
flow label is not supported yet in the real world, so widespread
use of reflection is years in the future.

There's no discussion of flow label rewriting by firewalls,
which we know from the 6man discussions before RFC 6437 is
a real issue. If the scope is strictly limited to a single
administrative domain, that's OK, but the general end-to-end
case probably fails.

Actually, the draft doesn't clarify exactly what is a session
for flow label purposes. As noted in the meeting, is a "stateless"
session (UDP request/reply) a session for this purpose? What
about multiple HTTP connections from the same client?

The uniqueness rule for flow labels is that a flow is identified
by the 3-tuple {Flow Label, Source Addr, Destination Addr}. The
flow label value itself might not be unique in the intermediate
nodes, so any state must be keyed by the 3-tuple, with the two
addresses either way round.

The mechanism seems very exposed to on-path attacks, since an
attacker could forge a reverse packet with the correct label,
even before the first TCP ACK. So nobody should rely on the flow
label alone for anything important. (I don't think there is any
new risk for off-path attacks.)

Finally I think the document would have more chance of success
if it was made Informational, without that SHOULD. Just describe
this as a use case for the flow label - it is completely consistent
with RFC 6437. If the original label is pseudo-random, it will
do fine as a reflected label from the other node.

Regards
   Brian

_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops

Liubing (Leo | 21 Jul 09:43 2014

FW: New Version Notification for draft-liu-v6ops-dhcpv6-slaac-guidance-02.txt


-----Original Message-----
From: internet-drafts@...
[mailto:internet-drafts@...] 
Sent: Monday, July 21, 2014 3:27 PM
To: Ron Bonica; Tianle Yang; Ron Bonica; Liubing (Leo); Tianle Yang; Liubing (Leo)
Subject: New Version Notification for draft-liu-v6ops-dhcpv6-slaac-guidance-02.txt

A new version of I-D, draft-liu-v6ops-dhcpv6-slaac-guidance-02.txt
has been successfully submitted by Bing Liu and posted to the IETF repository.

Name:		draft-liu-v6ops-dhcpv6-slaac-guidance
Revision:	02
Title:		DHCPv6/SLAAC Address Configuration Interaction Problem Statement
Document date:	2014-07-21
Group:		Individual Submission
Pages:		9
URL:            http://www.ietf.org/internet-drafts/draft-liu-v6ops-dhcpv6-slaac-guidance-02.txt
Status:         https://datatracker.ietf.org/doc/draft-liu-v6ops-dhcpv6-slaac-guidance/
Htmlized:       http://tools.ietf.org/html/draft-liu-v6ops-dhcpv6-slaac-guidance-02
Diff:           http://www.ietf.org/rfcdiff?url2=draft-liu-v6ops-dhcpv6-slaac-guidance-02

Abstract:
   ND and DHCPv6 protocols could have some interaction on address
   provisioning with the A, M, and O flags defined in ND protocol.  But
   the relevant standard definitions of the flags contain ambiguity, so
   that current implementations in operating systems have varied on
   interpreting the flags.  The variation might impact real network
   operations, so this document aims to provide some operational
   guidance to eliminate the impact as much as possible.

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.

The IETF Secretariat

_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops

Fred Baker (fred | 14 Jul 23:30 2014
Picon

Need jabber Scribe and minutes taker for v6ops at IETF 90

Reply to v6ops-chairs@..., please.

_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops
Fred Baker (fred | 14 Jul 23:29 2014
Picon

Agenda posted

The v6ops agenda for IETF 90 has been posted, at http://www.ietf.org/proceedings/90/agenda/agenda-90-v6ops

If you want to bash the agenda, reply to this email. That will save us time in the meeting.

_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops
Andrew Yourtchenko | 11 Jul 15:16 2014
Picon

IPv6 multicast WiFi power usage - draft-desmouceaux-ipv6-mcast-wifi-power-usage

hi all,

last IETF there were presentations about ND, multicast and power usage on 
the WiFi, the consensus was we need more data on it.

Yoann did a nontrivial amount of work on this subject in the meantime and 
we'd like to show it to you and hear your feedback.

http://tools.ietf.org/html/draft-desmouceaux-ipv6-mcast-wifi-power-usage-00

thanks a lot!

--a

_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops

Eric Vyncke (evyncke | 10 Jul 17:06 2014
Picon

Late addition to V6OPS agenda: segment routing for IPv6?

Fred and Joel,

You may be aware of segment routing whose architecture and MPLS version are discussed in the SPRING WG. But, there is also an IPv6 version discussed in 6MAN: 
  • draft-previdi-6man-segment-routing-header
  • draft-vyncke-6man-segment-routing-security-00

It is about a modified routing extension header to allow mainly for traffic engineering and or replace a MPLS LDP core by a native IPv6 one. Hence, there is a major (we hope) operational impact.

Stefano (in cc) and I understand that we are late in the process to get a slot in V6OPS, but, if you could get us a 10-minute slot on Monday AM or Tuesday PM, then we could present what are the goals & architecture of segment routing for IPv6 (which really leverages IPv6, hence perhaps 'the killing app' for IPv6 :-))

Thanks in advance and see you in Toronto

-éric
_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops

Gmane