Subject: [v6ops] I-D Action: draft-ietf-v6ops-64share-10.txt

From: [email-masked]
Date: Tue, 01 Apr 2014 16:14:47 -0700

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           : Extending an IPv6 /64 Prefix from a 3GPP Mobile Interface to a LAN link
        Authors         : Cameron Byrne
                          Dan Drown
                          Ales Vizdal
	Filename        : draft-ietf-v6ops-64share-10.txt
	Pages           : 9
	Date            : 2014-04-01

Abstract:
   This document describes requirements for extending an IPv6 /64 prefix
   from a User Equipment 3GPP radio interface to a LAN link as well as
   two implementation examples.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-64share/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-v6ops-64share-10

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-64share-10

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/

---

From: Vízdal Aleš <[email-masked]>
Date: Wed, 2 Apr 2014 01:20:00 +0200

IESG review remarks have been incorporated.

Ales

> -----Original Message-----
> From: v6ops [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Wednesday, April 02, 2014 1:15 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [v6ops] I-D Action: draft-ietf-v6ops-64share-10.txt
>
>
> 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.
>
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

Zásady komunikace, které společnost T-Mobile Czech Republic a.s. užívá při sjednávání smluv, jsou uvedeny zde  http://www.t-mobile.cz/zasady. Není-li v zásadách uvedeno jinak, nepředstavuje tato zpráva konečný návrh na uzavření či změnu smlouvy ani přijetí takového návrhu. The communication principles which T-Mobile Czech Republic a.s. applies when negotiating contracts are defined here http://www.t-mobile.cz/principles. Unless otherwise stated in the principles, this message does not constitute the final offer to contract or an amendment of a contract or acceptance of such offer.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 03 Apr 2014 13:28:05 +0200

Thanks for the update.

I am happy this document advances.

I don't comment after a IESG review, just a few points for when time allows:

- the term 'mobile network' is inconsistently used across this document
   and a published RFC.
- the method works for _a_ SLAACed (W)LAN -  it wouldnt scale beyond
   one such link.

Alex

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 3 Apr 2014 15:54:42 +0000

> I don't comment after a IESG review, just a few points for when time allows:

It’s harder to change now. Time would have allowed at an earlier date.

> - the term 'mobile network' is inconsistently used across this document

I’m not quite sure what you mean here. In this document, the term is used twice, in the second and third paragraphs of the security considerations section:

   Despite the use of temporary IPv6 addresses, the mobile network
   provided /64 prefix is common to all the LAN attached devices
   potentially concerning privacy. A nomadic device (e.g. a smartphone)
   provided IPv6 prefix is not a long lived one due to re-attaches
   caused by a device reload, traveling through loosely covered areas,
   etc.  The network will provide a new IPv6 prefix after a successful
   re-attach.

   3GPP mobile network capable CPEs (e.g. a router) are likely to keep
   the mobile network data connection up for a longer time.  Some mobile
   networks may be re-setting the mobile network connection regularly
   (e.g. every 24 hours) others may not.  Privacy concerned users shall
   take appropriate measures to not to keep their IPv6 prefixes long-
   lived.

In both cases, the term “mobile network” refers to the 3G/4G/LTE network operated by the network provider. The provider uses a common /64 across the devices connected to it in a cell, and those devices, whether traditional handsets or things more similar to traditional networking equipment but equipped with 3G/4G/LTE interfaces, might keep those connections up for a period of time.

There are 121 RFCs that use the term “mobile network”. Some, such as RFC 898 (dated 1984), predate commercial use of the term, and refer more to the packet radio experiments carried on by SRI in that timeframe. Per RFC 1726 (Requirements for IPng, 1994), the term is used at least to include

      Reference [6] discusses possible future use of IP-based networks
      in the US Navy's ships, planes, and shore installations.  Their
      basic model is that each ship, plane and shore installation
      represents at least one IP network.  The ship- and plane-based
      networks, obviously, are mobile as these craft move around the
      world. Furthermore, most, if not all, Naval surface combatants
      carry some aircraft (at a minimum, a helicopter or two). So, not
      only must there be mobile networks (the ships that move around),
      but there must be mobile internetworks: the ships carrying the
      aircraft where each aircraft has its own network, which is
      connected to the ship's network and the whole thing is moving.

By the way, I’m not convinced that it is accurate to say that these were “future” requirements; The use case existed in deployment at the time.

RFC 2002 uses the term to refer to a subnet in motion within a larger fixed network, or a network of individual devices in motion:

   A mobile node can be a router, which is responsible for the mobility
   of one or more entire networks moving together, perhaps on an
   airplane, a ship, a train, an automobile, a bicycle, or a kayak.  The
   nodes connected to a network served by the mobile router may
   themselves be fixed nodes or mobile nodes or routers.  In this
   document, such networks are called "mobile networks”.

If you’re referring to the now-common usage of commercial mobile networks based on cellular radio technology, yes, those are also referred to as “mobile networks”. But they are a relatively recent group to choose the term.

I’m not sure I understand your point. That the term has been used with multiple definitions in the RFC series?

See attached.

> - the method works for _a_ SLAACed (W)LAN -  it wouldnt scale beyond

That comment came up in working group discussion, I believe. Since that was the target use case, it was deemed an acceptable limitation. To scale to multiple (W)LANs, the device and the network would need to implement RFC 3633 or something equivalent to it.

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 04 Apr 2014 12:01:06 +0200

> It’s harder to change now. Time would have allowed at an earlier

Hi Fred,

This is not a request for a change.

>> - the term 'mobile network' is inconsistently used across this
>> document and a published RFC.
>
> I’m not quite sure what you mean here. In this document, the term is
> used twice, in the second and third paragraphs of the security
> considerations section:
>
> In both cases, the term “mobile network” refers to the 3G/4G/LTE
> network operated by the network provider.

Yes, but a 'mobile network' as defined by the mobility terminology RFC
has the mobile network be what this draft calls a 'LAN'.  And I agree, 
this draft calls a 'mobile network' what the mobility terminology RFC 
calls a 'mobile access network'.

This is even more complicated because we have here the cellular network
facing a LAN, but otherwise a mobile network facing another mobile network?

But yes - certainly, we are free to read this each in his/her own sense,
and understand it ok.

> The provider uses a common /64 across the devices connected to it in
> a cell, and those devices, whether traditional handsets or things
> more similar to traditional networking equipment but equipped with
> 3G/4G/LTE interfaces, might keep those connections up for a period
> of time.
>
> There are 121 RFCs that use the term “mobile network”.

Thanks, didn't know that.

> Some, such as RFC 898 (dated 1984), predate commercial use of the
> term, and refer more to the packet radio experiments carried on by
> SRI in that timeframe.

This use of 'mobile network' in RFC898 is consistent with the definition 
of a mobile network in the mobility terminology RFC.

> Per RFC 1726 (Requirements for IPng, 1994),
> the term is used at least to include
>
> Reference [6] discusses possible future use of IP-based networks in
> the US Navy's ships, planes, and shore installations.  Their basic
> model is that each ship, plane and shore installation represents at
> least one IP network.  The ship- and plane-based networks,
> obviously, are mobile as these craft move around the world.
> Furthermore, most, if not all, Naval surface combatants carry some
> aircraft (at a minimum, a helicopter or two). So, not only must there
> be mobile networks (the ships that move around), but there must be
> mobile internetworks: the ships carrying the aircraft where each
> aircraft has its own network, which is connected to the ship's
> network and the whole thing is moving.

This too, 'mobile network' consistent with the defitnition of mobile 
network in the mobilterminology RFC.

> By the way, I’m not convinced that it is accurate to say that these
> were “future” requirements; The use case existed in deployment at
> the time.

I agree.

> RFC 2002 uses the term to refer to a subnet in motion within a
> larger fixed network, or a network of individual devices in motion:
>
> If you’re referring to the now-common usage of commercial mobile
> networks based on cellular radio technology, yes, those are also
> referred to as “mobile networks”. But they are a relatively recent
> group to choose the term.

That is ok, but reflecting it in an RFC series exposes this duality in a 
different light, maybe contradictory in a sense.

> I’m not sure I understand your point. That the term has been used
> with multiple definitions in the RFC series?

My point is that the term 'mobile network' used in this draft is used in 
such a way (it designates the 3GPP fixed network which supports movement 
of mobiles around it, it does not designate the network that moves) that 
is inconsistent with the other RFCs.

>
> See attached.
>
>> - the method works for _a_ SLAACed (W)LAN -  it wouldnt scale
>> beyond one such link.
>
> That comment came up in working group discussion, I believe. Since
> that was the target use case, it was deemed an acceptable
> limitation. To scale to multiple (W)LANs, the device and the network
> would need to implement RFC 3633 or something equivalent to it.

YEs, I agree to this point.

The draft does not say it, but people should know.

For example, in one particular case, just an example: trying to connect 
a vehicle to an IPv6-only cellular infrastructure may be tempted by 
64share, or by NPT, but may realize that because there are typically 
several subnets in a vehicle, and because the cellular only gives a /64, 
neither 64share nor NPT may prove attractive candidates.

Alex

>>>> -----Original Message----- From: v6ops
>>>> [mailto:[email-masked]] On Behalf Of
>>>> [email-masked] Sent: Wednesday, April 02, 2014 1:15
>>>> AM To: [email-masked] Cc: [email-masked] Subject:
>>>> [v6ops] I-D Action: draft-ietf-v6ops-64share-10.txt
>>>>
>>>>
>>>> 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           : Extending an IPv6 /64 Prefix from a 3GPP
>>>> Mobile Interface to a LAN link Authors         : Cameron Byrne
>>>>  Dan Drown Ales Vizdal Filename        :
>>>> draft-ietf-v6ops-64share-10.txt Pages           : 9 Date :
>>>> 2014-04-01
>>>>
>>>> Abstract: This document describes requirements for extending
>>>> an IPv6 /64 prefix from a User Equipment 3GPP radio interface
>>>> to a LAN link as well as two implementation examples.
>>>>
>>>>
>>>> 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.
>>>>
>>>> _______________________________________________ v6ops mailing
>>>> list [email-masked]
>>> Zásady komunikace, které společnost T-Mobile Czech Republic a.s.
>>> užívá při sjednávání smluv, jsou uvedeny zde
>>> http://www.t-mobile.cz/zasady. Není-li v zásadách uvedeno jinak,
>>> nepředstavuje tato zpráva konečný návrh na uzavření či změnu
>>> smlouvy ani přijetí takového návrhu. The communication
>>> principles which T-Mobile Czech Republic a.s. applies when
>>> negotiating contracts are defined here
>>> http://www.t-mobile.cz/principles. Unless otherwise stated in the
>>> principles, this message does not constitute the final offer to
>>> contract or an amendment of a contract or acceptance of such
>>> offer.
>
>
>
>
>

---

From: Ole Troan <[email-masked]>
Date: Mon, 7 Apr 2014 10:35:50 +0200

shouldn't this document reference Appendix A of RFC4389 specifically?
if not also RFC4903.

cheers,
Ole