Subject: Re: [v6ops] example method (was: single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt)

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 13 Dec 2012 18:06:36 +0100

Le 27/08/2012 10:54, Lorenzo Colitti a écrit :
> Ok, so how about the following? Comments welcome.
>
> 0. If you get a DHCPv6 prefix delegation: congratulations. You live in
> the glorious future. Your carrier has a release 10 network, and is
> providing you with tethering (either because they're a just that nice,
> or because you paid extra for the privilege). The CLAT simply behaves
> like an RFC 6204 router. Done.
>
> Now for the rest of us. Since we're still here, it means we only have a
> single /64. If you don't want to implement tethering, do nothing. If you
> do want to implement tethering, proceed as follows (cell0 is the
> upstream interface, wlan0 is the downstream):
>
> 1. Enable tethering only when cell0 is a point-to-point interface (e.g.,
> 3G, LTE, ...).
> 2. When enabling tethering, take the IPv6 address of cell0 (which you
> were already using, and need to continue to use because you have open
> connections to it), and assign it to wlan0 instead of cell0
> 3. Treat cell0 as unnumbered; when sending out packets, use the IP
> address assigned to wlan0.
> 4. Forward IPv6 unicast packets from wlan0 to cell0 and vice versa like
> a standard IPv6 router (decrement TTL, etc.)
> 5. Forward IPv6 multicast packets from wlan0 to cell0 and vice versa
> like a standard IPv6 multicast router (But I don't know anything about
> multicast, so I'll shut up now.)
> 6. Send an RA for the /64 to wlan0. If hosts pick the same IID as you,
> they will fail DAD.
>
> So far so good. There is no bridging, and since the upstream is a
> point-to-point interface, there are no loops.

The above method describes how this was made to work.  We here have 
tried it, approximately, and we came up with the following two 
alternative methods  - one ok, one not ok.

On the UE CLI us traditional 3G+ ptp connections, in this order, and it 
works ok.
- set forwarding to 1 (and loose ability to configure default route
   upon reception of RA).
- put ppp0 up
- put eth0 up
- read the address assigned on ppp0 and assign it on eth0 with plen 64
- update radvd.conf/eth0 to put that /64 prefix
- add default route through ppp0 (has to be done manually, because ppp0
   didnt do it and being a router ignores the default route part of the
   RA).

On the UE use new LTE USB key which support CDC-Ethernet.  This LTE USB 
key has a IEEE-assigned MAC address despite being 3GPP.  On CLI do this:
- set forwarding to 1.
- put wwan0 up
- put eth0 up
- read address on wwan0 and assign it on eth0
- update radvd.conf/eth0 to put that /64 prefix
- add default route through wwan0.

On this configuration the operator's router (GGSN?) sends NS on the 
wwan0 interface for any dst address derived of that /64.  The UE does 
not respond to such an NS, it only responds to the NS for the address 
which it formed to self.  (This can be solved by either proxyND or by 
maybe operator adding a Full route (instead of currently a Connected 
Route).  OR other.)

Alex

Note that this is *not*
> RFC 4389. But it does not need to be.
>
> We haven't talked about CLAT yet. There are two cases here:
>
> 1. The CLAT implementation can use the same IPv6 address as the phone.
> In this case, no problem.
> 2. The CLAT implementation cannot use the same IPv6 address as the
> phone. In this case, either:
>    a) the CLAT does DAD for that other address as well, or:
>    b) picks an address that "shouldn't collide" (remi's reserved IID)
>
> It's as simple as that. So, as far as I can see, the only issue left to
> discuss is "do we do 2a or 2b"?
>
> On Mon, Aug 27, 2012 at 10:09 AM, Hemant Singh (shemant)
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Victor (and also replying to Rajiv in one email),
>
>     -----Original Message-----
>     From: Victor Kuarsingh [mailto:[email-masked]
>     <mailto:[email-masked]>]
>     Sent: Sunday, August 26, 2012 8:04 PM
>     To: Hemant Singh (shemant)
>     Cc: [email-masked] <mailto:[email-masked]>
>     Subject: Re: [v6ops] single /64, ND Proxy, and
>     draft-ietf-v6ops-464xlat-07.txt
>
>      >I cannot speak for every operator, but for some of us trying to deploy
>      >IPv6, if I cannot do it with tethering, I cannot deploy it (part
>     of the
>      >service). Not supporting tethering would inhibit my ability to
>     deploy (in
>      >my case - perhaps for others).
>
>     Got it - you need tethering immediately.  Ok, back to the ND Proxy
>     issues then.
>
>     My wife turns on her cell phone and this CLAT phone uses the
>     reserved IID and thus does not issue any RA with the ND Proxy P-bit.
>       A tethered client in a home IPv6 router uses the RA to get a SLAAC
>     IPv6 address.  Behind the IPv6 CPE router is a network bridge.
>     Subsequently, I turn on my cell phone that supports only an ND Proxy
>     and a single /64.  Before my phone is able to send an RA with the
>     P-bit set, the bridged behind home router looped my wife's phone RA
>     to my phone and my phone loops the RA back to the SP.  Additionally,
>     what does my tethered client do if the client receives two different
>     RA's as described above and specifically how is proxying of NA's
>     done?  Is the NA sent to the ND Proxy phone or the reserved IID
>     phone when the tethered node has only one interface to receive an NS on?
>
>     Soon as one says tethering, testing for what is working code is very
>     broad because there could be whole network behind one tethered
>     client.  This is the same point Ray Hunter is making and it would be
>     good to reply to his email at the URL below.
>
>     http://www.ietf.org/mail-archive/web/v6ops/current/msg13960.html
>
>     Regards,
>
>     Hemant
>
>
>
>     _______________________________________________
>     v6ops mailing list
>     [email-masked] <mailto:[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: Tue, 18 Dec 2012 11:32:18 +0900

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

> key has a IEEE-assigned MAC address despite being 3GPP.  [...]
> On this configuration the operator's router (GGSN?) sends NS on the wwan0
> interface for any dst address derived of that /64.

Do you know for sure that the operator's router is sending the NS message?
Could it be the USB key faking it?

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 18 Dec 2012 09:05:51 +0100

Le 18/12/2012 03:32, Lorenzo Colitti a écrit :
> On Fri, Dec 14, 2012 at 2:06 AM, Alexandru Petrescu
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>
> On the UE use new LTE USB key which support CDC-Ethernet.  This LTE
> USB key has a IEEE-assigned MAC address despite being 3GPP.  [...]
> wwan0 interface for any dst address derived of that /64.
>
>
> Do you know for sure that the operator's router is sending the NS
> message? Could it be the USB key faking it?

If it is the key faking it then it is a very good fake.

The NS is sent at the reception of a EchoReply (initially, an
EchoRequest was sent by the UE towards a CN on the internet).  The
EchoReply is not delivered to the UE until a NA is sent by the UE.

The src address of the NS is that of the Gateway - the same as the
next-hop of the default route entry in the rt table.  The Source link
layer address field in NS is that of the Gateway (and not of the key;
the key has a different Source link layer address).  It is the same
Source link layer address as present in the RA.

That makes me think it is not the key faking it.  If it is faked then it
is a very good fake.

Also, if this NS is a key-fake then is not somethink I could influence
on the classic IP stack on the computer.

Alex

---

From: Jouni Korhonen <[email-masked]>
Date: Tue, 18 Dec 2012 14:55:27 +0200

Alex,

> If it is the key faking it then it is a very good fake.

A lot can be done in a modem firmware.

> EchoReply is not delivered to the UE until a NA is sent by the UE.

In order to stop the "guess work" why don't you say whose USB dongle and
whose GGSN you are testing against. Even more nicer would be providing
a GTP capture ;)

> Source link layer address as present in the RA.

Please, don't keep saying "the SLLA of the GW" since the link technology
has none. And yes, some gateways synthesise those but they still are not
real link-layer addresses per se. Just there to keep sad software happy..

- Jouni

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 18 Dec 2012 15:08:04 +0100

Le 18/12/2012 13:55, Jouni Korhonen a écrit :
>>> <[email-masked]
>>> <mailto:[email-masked]>> wrote:
>>>
>>> On the UE use new LTE USB key which support CDC-Ethernet.  This
>>> LTE USB key has a IEEE-assigned MAC address despite being 3GPP.
>>> [...] On this configuration the operator's router (GGSN?) sends
>>> NS on the wwan0 interface for any dst address derived of that
>>> /64.
>>>
>>>
>>> Do you know for sure that the operator's router is sending the
>>> NS message? Could it be the USB key faking it?
>>

I don't doubt that.

> In order to stop the "guess work" why don't you say whose USB dongle
> and whose GGSN you are testing against. Even more nicer would be
> providing a GTP capture ;)

For the key I thought I already said, it's a bandrich.  The software is
CDC-Ether on recent linux with qmi.

Whose GGSN - I believe it is 208 01 and 02.

The GTP capture - can I obtain it on the UE?  How?

I can send wireshark dumps of the RA, and the NS, on that interface of
UE, and the state of the rt table and ifconfig on UE.

>> next-hop of the default route entry in the rt table.  The Source
>> link layer address field in NS is that of the Gateway (and not of
>> the key; the key has a different Source link layer address).  It is
>> the same Source link layer address as present in the RA.
>
> Please, don't keep saying "the SLLA of the GW" since the link
> technology has none. And yes, some gateways synthesise those but they
> still are not real link-layer addresses per se. Just there to keep
> sad software happy.

Does the Gateway has a link-local address?

The SLLA present in the RA sent by the Gateway is part of the IID of
that link-local address.

Whether it's the CDC-Ether who makes that up (intercept RA sent by 
Gateway, read ll address, fake a SLLA, insert in RA, update the len 
fields, etc.) - then that's another matter.

Alex

>
> - Jouni
>
>> That makes me think it is not the key faking it.  If it is faked
>> then it is a very good fake. Also, if this NS is a key-fake then is
>> not somethink I could influence on the classic IP stack on the
>> computer.
>>
>> Alex
>>
>>
>> _______________________________________________ v6ops mailing list
>> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>