Subject: Re: [v6ops] new draft: draft-byrne-v6ops-64share

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 13 Dec 2012 17:26:39 +0100

Le 30/09/2012 04:56, Tony Hain a écrit :
> It is not required that the same address be assigned on both
> interfaces, just that the UE must defend and respond for the address
> used on the wan interface as if it was connected to the lan.

LEt me bring back this topic, after a few experiments.

The requirement that UE defends that address is only required only when
the cellular link is not point-to-point (i.e. it is Ethernet-compatible,
like CDC-Ethernet, and does ND).

In other more mundance cases like ptp links with ppp software the Access
Router on that ptp link will never send NS (it's a 'no ARP' interface)
and have a connected route and just deliver.  And on these ptp links the
64share trick of re-advertising the received /64 works without proxy ND.

Alex

  I can't think of any cases
> where using the duplicated address breaks anything, but it does seem
> like there might be some diagnostic benefit to having a predictable
> offset on the lan interface address. It is not like there is a
> shortage of addresses and we need to duplicate as a conservation
> measure... ;)
>
> Tony
>
>> -----Original Message----- From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Cameron Byrne Sent:
>> Saturday, September 29, 2012 2:51 PM To: Eric Vyncke (evyncke) Cc:
>> [email-masked]; [email-masked] Subject:
>> Re: [v6ops] new draft: draft-byrne-v6ops-64share
>>
>> On Sat, Sep 29, 2012 at 2:27 PM, Eric Vyncke (evyncke)
>> <[email-masked]> wrote:
>>> Isn't it easier to copy the MTU option from the RA received by
>>> the handset to the RA sent on the LAN? Of course, when there is
>>> no MTU option in the received RA on the WAN link, then, a SHOULD
>>> set MTU option to 1480 seems good
>>>
>>
>> Yes, this will be the logic that we will bring to the text of
> draft-binet-v6ops-
>> cellular-host-reqs-rfc3316update
>>
>> CB
>>
>>> -éric
>>>
>>>> -----Original Message----- From: [email-masked]
>>>> [mailto:[email-masked]] On Behalf Of Cameron Byrne
>>>> Sent: samedi 29 septembre 2012 21:26 To: Mikael Abrahamsson
>>>> Cc: [email-masked]; [email-masked]
>>>> Subject: Re: [v6ops] new draft: draft-byrne-v6ops-64share
>>>>
>>>> On Sat, Sep 29, 2012 at 10:35 AM, Mikael Abrahamsson
>>>> <[email-masked]> wrote:
>>>>> On Sat, 29 Sep 2012, [email-masked] wrote:
>>>>>
>>>>>> A new draft has been posted, at
>>>>>> http://tools.ietf.org/html/draft-byrne-v6ops-64share.
>>>>>> Please take a look at it and comment.
>>>>>
>>>>>
>>>>> I have read it and support that it's a valuable topic to
>>>>> publicise an RFC on.
>>>>>
>>>>> The last paragraph of section 3 about MTU makes sense, but I
>>>>> would like to see a little bit more elaboration on why 1440
>>>>> was chosen (rationale). I understand the rationale, but I am
>>>>> not sure all readers of
>>>> the document do.
>>>>>
>>>>
>>>> I tried to keep it concise, and the MTU issue is quite
>>>> important and does require explanation, as you mentioned ...
>>>> but on thinking it over more, it would be better to simply
>>>> reference this behavior in the more comprehensive
>>>> draft-binet-v6ops-cellular-host-reqs-rfc3316update
>>>>
>>>> So, i will remove the MTU bit from draft-byrne-v6ops-64share
>>>> and just make sure it gets covered well in
>>>> draft-binet-v6ops-cellular-host-reqs- rfc3316update
>>>>
>>>> FYI to folks that might be lost here. The 3GPP architecture is
>>>>  heavily reliant on IP-in-IP/UDP tunnels called GTP (GPRS
>>>> tunneling
>> protocol).
>>>> More often than not, the infrastructure links are set at 1500
>>>> bytes, the cell phone interface is 1500 bytes, and therefore
>>>> the GTP tunnels packets need to fragmented since they are
>>>> carrying 1500 byte tunneled packets within an IP packet that
>>>> will no longer fit on a 1500 byte link.  Not pretty.  So,
>>>> sometimes the carriers get the handsets manually set to a
>>>> lower MTU. And, sometimes the HTTP proxies reset the
>> MSS to avoid fragments.
>>>>
>>>> Given that RA can advertise MTU, this is a good opportunity to
>>>>  properly and dynamically set the mobile device's MTU without
>>>> causing lots of fragment reassembly state in the network or
>>>> otherwise mucking with MSS.  This will also be relevant and
>>>> true for devices on the tethered LAN since all those packets
>>>> will be put into the MTU constrained GTP tunnels on their way
>>>> through the mobile provider and to
>> the Internet.
>>>>
>>>> CB
>>>>
>>>>> -- Mikael Abrahamsson    email: [email-masked]
>>>>>
>>>>> _______________________________________________ v6ops
>>>>> mailing list [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>> _______________________________________________ v6ops mailing
>>>> list [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/v6ops
>> _______________________________________________ v6ops mailing list
>>  [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>
> _______________________________________________ v6ops mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 14 Dec 2012 13:11:00 +0900

On Fri, Dec 14, 2012 at 1:26 AM, Alexandru Petrescu <
[email-masked]> wrote:

> In other more mundance cases like ptp links with ppp software the
> AccessRouter on that ptp link will never send NS (it's a 'no ARP'
> interface) and have a connected route and just deliver.  And on these ptp
> links the 64share trick of re-advertising the received /64 works without
> proxy ND.
>

No, it won't work. Suppose I turn on /64 sharing on my phone, and the phone:

1. Is connected to the IPv6 Internet through its cell interface (which is a
point-to-point link).
2. Is sharing 2001:db8::/64
3. Has IPv6 address 2001:db8::dead:beef. (It must have an IPv6 address on
its cell interface, or it can't reach the IPv6 Internet).

If a host behind the phone autoconfigures the address 2001:db8::dead:beef,
it will not be able to receive replies from the Internet. It can send
packets from 2001:db8::dead:beef, and the phone will (probably) send them
to the Internet, but when as someone on the Internet sends a packet to
2001:db8::dead:beef, the phone will receive it through the cellular
interface and terminate it - because that address belongs to the phone.

So the host needs to be told "don't use 2001:db8::dead:beef, because it
belongs to someone else on this link". DAD is the way to do that.

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 14 Dec 2012 10:41:16 +0100

Le 14/12/2012 05:11, Lorenzo Colitti a écrit :
> On Fri, Dec 14, 2012 at 1:26 AM, Alexandru Petrescu
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>
> The requirement that UE defends that address is only required only
> when the cellular link is not point-to-point (i.e. it is
> Ethernet-compatible, like CDC-Ethernet, and does ND).
>
> interface) and have a connected route and just deliver.  And on
> these ptp links the 64share trick of re-advertising the received /64
> works without proxy ND.
>
>
> 1. Is connected to the IPv6 Internet through its cell interface
> (which is a point-to-point link). 2. Is sharing 2001:db8::/64 3. Has
> IPv6 address 2001:db8::dead:beef. (It must have an IPv6 address on
> If a host behind the phone autoconfigures the address
> 2001:db8::dead:beef, it will not be able to receive replies from the
> Internet. It can send packets from 2001:db8::dead:beef, and the phone
> will (probably) send them to the Internet, but when as someone on the
> Internet sends a packet to 2001:db8::dead:beef, the phone will
> receive it through the cellular interface and terminate it - because
> that address belongs to the phone.

Yes, and there are several ways to avoid that.

One of them is to substitute 2001:db80::1 for 2001:db80::dead:beef on
the cell iface of UE.  A laptop on a LAN would rarely if ever
self-configure an address ending with ::1.  This was suggested
by somebody else.

> So the host needs to be told "don't use 2001:db8::dead:beef, because
> it belongs to someone else on this link". DAD is the way to do that.

Yes, this way of dealing with the above problem is to trigger DAD on the
LAN iface of UE by assigning it same 2001:db80::dead:beef as assigned on
the cell iface of UE.

Alex