Re: [v6ops] Comments on draft-ietf-v6ops-64share

[Cameron Byrne <[e-mail]>]

Alex,

Thanks for the detailed review.

I am considering adding 2 more scenarios in addition to the one
already described

1) The UE only has LLA, and just relays the 3GPP RA announced /64 to
the LAN.  In this case, the UE is effectively off-line while tethering
since it does not have a global address, it is just doing a router
function.

2) The same as above, but the UE assigns itself an address on the LAN.
 This avoids the multiple interface address issue.

3) Maintain the existing method which allows for long lived
connections and is the running Android code that we have.

If those 3 methods are defined, the solution becomes more general, so
i would like feedback from the group on if the document should move to
BCP , become more general, and remove all 3GPP related language.

The BCP would say 1) Do DHCPv6-PD 2) when DHCPv6-PD is not available
for whatever reason, these 3 method can support extending a /64 subnet
from a WAN to a LAN.

In Atlanta, there was discussion about the need for a more general solution.

CB

On Thu, Jan 24, 2013 at 9:38 AM, Alexandru Petrescu
<[e-mail]> wrote:
> Cameron, thank you for the new version, and as WG item.
>
> I have some comments below, if time allows.  This is my personal oppinion.
>
> Le 20/01/2013 02:23, Cameron Byrne a écrit :
>>
>> Hi,
>>
>> I posted this update as a WG draft
>>
>> http://tools.ietf.org/html/draft-ietf-v6ops-64share-00
>>
>> Please take the time to review this update and share your feedback. I
>> hoping that a clearly defined scope, clear need for this work,  as
>> well running code will make it easy to advance. I am now aware of 3
>> implementations that approximately use this method (ios6, an LTE mifi
>> router, and Dan Drown's Android submission)
>
>
> Well, in addition to this mostly handheld mobile device implementations,
> one could add a larger PC variable platform for deploying in vehicles -
> a Mobile Router using ubuntu linux, on atom 32bit and 64bit, with 3G,
> LTE-in-3G-mode testing using nokia, icon, bandrich and huawei USB keys
> and miniPCI 3G+, with ppp and qmi.
>
> The method described in the draft was tested, as well as some variations
> of it (e.g. assign the IP address solely on the LAN interface and remove
> it from the WWAN interface; configure the IPv6 address from RA or
> scripted, on ptp link or on Ethernet 'emulated' link, etc.).
>
> BAsed on that experience I comment on the draft below.
>
>> This document describes a known and implemented method of sharing a
>> /64 IPv6 prefix from a User Equipment 3GPP radio interface to a
>> tethered LAN.
>
>
> This is a terminology discussion, but I have some issues digesting this
> use of the word 'sharing'.  It is not blocking comments, and we could
> pursue with it ok.
>
> 'Sharing' one personal 3G subscription with several other users is ok.
> But 'sharing' a prefix across two links - especially if it's a /64 - is
> very hard to understand.
>
> Or we could find something else instead of 64sharing.  Sounds to me more
> like
> 'extending the use of a /64 beyond the link initially allocated' or
> 'making a Host into a Router when only one /64 prefix  is valid on only
>  one of its interfaces which is a Ethernet-compatible' or
> 'Point-to-Point IPv6 extended with a shared Ethernet'
>  or something else.
>
> The problems I have are about this '64' which sounds like '6 to 4', as
> if we used the IPv4 cell connection to form an IPv6 prefix for WLAN.
> And with the 'sharing', because the prefix is not shared at all - it is
> _moved_ from one interface to the other.
>
> I am using a lot the term 'shared link' (between Hosts on a link) and
> and they are not as in the way described in this draft.
>
> I also have problems with the word 'tethering' because in many cases
> there's actually no tether - it's without wires (exception USB cable or
> Ethernet cable).  With the vehicle case, the PC Mobile Router has most
> likely wireless interfaces.
>
>> this document describes how the 3GPP UE interface assigned /64 subnet
>> may be shared from the 3GPP interface to a tethered LAN.
>
>
> That /64 is maybe little 'assigned' - I think it is rather 'announced'
> on that ptp link.
>
> The 3GPP uses indeed the term 'assign a /64 to a UE' but I dont like it.
>
>> This is achieved by specifying the UE 3GPP interface as an IPv6 /128
>> subnet taken from the 3GPP interface's network assigned /64 subnet.
>
>
> This has formulation and content problems, to my reading.  I will follow
> it whether it evolves.
>
>> Then, assign the same address to the tethered LAN interface with the
>> full /64 subnet.
>
>
> This has formulation problems.  How about:
> "Then, assign that address to the ingress interface, and set its prefix
>  length on that interface as 64".
>
> 'tethered LAN' has problems because often it's WLAN and W means no
> tether.  Reading 'tethered LAN' makes think that this does not work on
> WLAN or WPAN.
>
>> The /64 tethered LAN subnet will then be advertised to the tethered
>> LAN via Router Advertisements (RA) [RFC4861].
>
>
> "The prefix and the prefix length received in the PIO in the RA on the
>  cellular interface are copied in the PIO in the RA sent on the ingress
>  interface".  This is a non-typical operation (not seen elsewhere,
>  other than maybe Router Renumbering) and yes deserves mentioning.
>
>> The end result is that all UE interfaces have link-local IPv6
>> addresses, the UE's 3GPP interface has a /128 address from the 3GPP
>> network assigned /64, and the same address that is assigned to the
>> 3GPP interface is assigned to the tethered LAN interface with a /64
>> subnet and advertised to the LAN via RA.
>
>
> This is too long, and a bit illogic, and a bit for discussion.
>
> Each UE interface does indeed have a ll address, but this is due to
> architecture spec, not an end result of this spec.
>
> 'UE 3GPP iface has a /128 address' - any other address is a /128,
> suffices it to say 'an address'.
>
> It is not necessary for the UE to keep that global address (derived from
> the IID of the interface, together with the PIO in the received RA).  It
> can remove it altogether from the egress interface.
>
> Besides, when it becomes a Router, the UE will no longer self-configure
> an address based on the RA (and its IID) - it will just log the
> reception of that RA.
>
>> This approach only impacts the UE configuration and does not require
>>  any changes to the 3GPP network.
>
>
> Yes, I agree, and deserves being mentioned.  This is an important aspect
> which may lead to widespread deployment.  I'd even stress that it does
> not need any changes to the 3GPP network nor to any other entity in the
> 3GPP network or elsewhere in the Internet.
>
>> Neighbor Discovery Proxy (ND Proxy) [RFC4389] functionality has been
>> suggested as an option for sharing the assigned /64 from the 3GPP
>> interface to the LAN, but ND Proxy is an experimental protocol and
>> has some limitations with loop-avoidance.
>
>
> ... and issues with security - proxying for somebody without that
> somebody agreeing to be represented may be seen as a leap of faith.
>
>> As [RFC6459] describes, the 3GPP network assigned /64 is completely
>> dedicated to the UE and the gateway does not consume any of the /64
>> addresses.  The gateway routes the entire /64 to the UE
>
>
> Yes.  The method described in this document works because the gateway
> does not issue a NS for an IP address prefixed by the announced prefix
> on that link.  The gateway considers (1) the route to be all towards a
> device, instead of towards a next-hop IP address (the route is expressed
> as a triplet "prefix-0-device" instead of "prefix-nexthop-device"), and
> (2) the link of the device to be point-to-point, with maximum two
> addresses on that link, and each address with link-local scope and (3)
> when the gateway needs  to deliver a packet whose destination address
> matches that prefix in its routing table, it will not issue a NS to
> obtain the MAC address of the destination address.
>
>> and does not perform ND or Network Unreachability Detection (NUD)
>> [RFC4861].
>
>
> Yes, too.
>
>> Communication between the UE and the gateway is only done using link-
>> local addresses and the link is point-to-point.
>
>
> Well I am not sure about the first part.
>
> I haven't seen much communication exclusively between the UE and the
> gateway (other than maybe the RAs).
>
> And, even if one removes the global address from the 3GPP interface (and
> assigns it on the ingress interface) it is still  possible for the
> gateway to communicate to the UE by using their respective global address.
>
> However, some things which are more sure are: (1) the RA is sent to the
> a link-scoped multicast address, and with a link-local src address (2)
> the nexthop field of the default route entry in UE's routing table is a
> link-local address, etc.
>
>> This allows for the UE to use the 3GPP network assigned /64 to
>> assign itself a /128 address to the 3GPP radio interface for
>> consistent network connection formation and the same address with a
>> /64 to the tethered LAN interface.
>
>
> Again this is too long.
>
> I can understand it, but it could be shortened and I could propose if
> needed.
>
>> The tethered LAN interface may then advertise the /64 to the LAN with
>> RA.  The LAN interface RA configuration must be tightly coupled with
>> the 3GPP interface state. If the 3GPP interface goes down or changes
>> address, that state should be reflected in the LAN IPv6
>> configuration.
>
>
> YEs.
>
>> Just as in a standard IPv6 router, the packet TTL will be
>> decremented when passing packets between interfaces.
>
>
> Yes, and just as in a standard IPv6 Router, the UE will no longer form
> an IPv6 address at the reception of the RA on its egress interface (not
> as when it did when it was a Host).
>
>> The procedure may also be described in terms of the following usage
>> example:
>
>
> Yes, I read it and it works.
>
> Alternatively, one could describe a method with deletion of the Address
> from the egress interface.
>
> Alex
> PS:
>>
>> 4.  The UE copies the address 2001:db8:ac10:f002:1234:4567:0:9 with
>> a 64 bit mask from the 3GPP interfaces to the wireless LAN interfaces
>>  and begins announcing the prefix 2001:db8:ac10:f002::/64 via RA to
>> the wireless LAN.
>
>
> (this is an example where it's written 'wireless LAN interfaces' and
> which means precisely the same that was referred to earlier as 'tethered
> LAN' - yet tether is not wireless).
>
>> 6.  The UE directly processes all packets destine to itself at
>> 2001:db8:ac10:f002:1234:4567:0:9.
>
>
> 'destined'.  And last 0 could be omitted or made an 8 instead.
>
>>
>> The UE should be compliant with the relevant requirements in [I-
>> D.draft-binet-v6ops-cellular-host-requirement].
>
>
> In particular, it should not run QMI and not present the ptp link to the
> IP stack as a Ethernet link with MAC addresses.  Otherwise the method in
> this document will fail.
>
>> 4. Security Considerations
>
>
> There is security problem if the operator of that 3GPP link does not
> want to allow several Hosts behind a single one.  This problem is bigger
> when the link is LTE because the larger bandwidth (and lower latencies)
> compared to 3G will lead to more opportunities to share one LTE
> connection with more users.
>
> Alex
>
>>
>> CB
>>
>> Sent from ipv6-only Android
>>
>>
>>
>> _______________________________________________ v6ops mailing list
>> [e-mail] https://www.ietf.org/mailman/listinfo/v6ops
>>
>
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops