Subject: Re: [v6ops] NUD and draft-byrne-v6ops-64share-03

From: Julien Laganier <[email-masked]>
Date: Tue, 11 Dec 2012 11:48:28 -0800

On Thu, Nov 29, 2012 at 12:17 AM, jouni korhonen <[email-masked]>wrote:

>
> On Nov 28, 2012, at 7:52 PM, Julien Laganier wrote:
>
> > Rajiv and Jouni,
> >
> >
> > On Sun, Nov 25, 2012 at 4:58 AM, jouni korhonen <[email-masked]>
> wrote:
> > Hi,
> >
> > On Sun, Nov 25, 2012 at 12:07 PM, Rajiv Asati (rajiva) <[email-masked]>
> wrote:
> > >
> > > Indeed. No DAD by GGSN/PGW for the /64 assigned to the UE.
> >
> > Correct.
> >
> >
> > I know that there's no DAD for addresses in the /64.
> >
> > My comment was about NUD...
>
> And no NUD either.
>

When you say that PGW/GGSN don't do NUD, are you talking about a standard
specification, or an implementation?

--julien

---

From: Jouni Korhonen <[email-masked]>
Date: Tue, 11 Dec 2012 23:03:19 +0200

On Dec 11, 2012, at 9:48 PM, Julien Laganier <[email-masked]> wrote:

> When you say that PGW/GGSN don't do NUD, are you talking about a standard specification, or an implementation?
> 
> --julien

Both. For the specification part, I admit, I felt a bit uneasy with my statement ;) However, I do not see a reason why to do so, since the /64 independent of the IID gets forwarded to the UE in any case.

- Jouni

---

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

Le 22/11/2012 02:14, Julien Laganier a écrit :
> Hello,
>
> I have a question regarding the interaction between NUD and the
> method described in this draft.
>
> The GGSN/PGW acting as a default router advertises via IPv6 RAs a
> /64 prefix over the point-to-point link to the User Equipment.
>
> Assuming the User Equipment employs the method described in this
> draft and uses "the 3GPP network assigned /64 to assign itself a
> /128 subnet address to the 3GPP radio interface for consistent
> network reachability and the same address with a /64 subnet to the
> tethered LAN interface.The tethered LAN interface may then advertise
> the /64 subnet to the LAN with RA."
>
> Now a host on the tethered LAN will configure an IPv6 address with
> SLAAC based on the advertized /64, and starts to use it.
>
> When a downlink packets sent towards a host on the tethered LAN
> arrives at the GGSN/PGW, who believes the /64 is onlink, if the
> GGSN/PGW attempts NUD towards that destination address, in the
> current description of the method the UE will not reply (it has
> configured only one /128 on its interface facing the 3GPP network).
> Thus it seems GGSN/PGW initiated NUD will fail.
>
> So it seems to me that the current method would work only if a) the
> GGSN/PGW doesn't perform NUD for downlink packets sent over the
> point-to-point link,

I agree, the current method  will  work if the Access Router does not
make NS towards the User Equipment for the IP address of a Host within
the LAN.  If it does, and the UE doesn't answer then communication fails.

This way of _not_ doing ND on ptp links is natural with many cellular
links, but non-natural with _some_ cellular connections (CDC-Ethernet).

Some operators of cellular links support both ways in the same cellular
network (i.e. the UE decides, not the operator, whether to start a noARP
ppp connection or start a ND-enabled CDC-Ethernet, using same SIM card,
on same operator).

Alex

> or b) the UE answers NUD probes for all addresses in the /64.
>
> Is this correct?
>
> Thanks,
>
> --julien
>
>
>
>
> _______________________________________________ v6ops mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>

---

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

Le 22/11/2012 04:47, Cameron Byrne a écrit :
> On Wed, Nov 21, 2012 at 5:14 PM, Julien Laganier
> <[email-masked]> wrote:
>> Hello,
>>
>> tethered LAN interface.The tethered LAN interface may then
>> advertise the /64 subnet to the LAN with RA."
>>
>> configured only one /128 on its interface facing the 3GPP
>> network). Thus it seems GGSN/PGW initiated NUD will fail.
>>
>> So it seems to me that the current method would work only if a)
>> the GGSN/PGW doesn't perform NUD for downlink packets sent over
>> the point-to-point link, or b) the UE answers NUD probes for all
>> addresses in the /64.
>>
>> Is this correct?
>>
>
> AFAIK, the GGSN/PGW does not do NUD.  The /64 is considered off-link
>  [1] and therefore no host resolution is done

I think he meant ND (its ip-mac resolution part), not just the
particular unreachability detection NUD.

AFAIK there exist operators which do ND on the cellular links, in some
cases.

BEsides always sending RA on cellular links, it may send NS if it's
EThernet compatible.

The section you cite in [1] has several problems (i.e. it's wrong),
especially with respect to its claims vs 3GPP specs vs deployments, but
we could discuss separately.

Alex

>
> [1] http://tools.ietf.org/html/rfc6459#section-5.2
>
>
>
>
>
> CB
>
>> Thanks,
>>
>> --julien
>>
>>
>>

---

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

> Indeed. No DAD by GGSN/PGW for the /64 assigned to the UE.

One does not do a DAD on a prefix (be it /64 or any <128), right?

DAD would need to be done by the UE not by GGSN/PGW.

I haven't seen DAD on these links but I may try to find.

DAD is just one part of ND, others are NUD, SLAAC, etc.

> BTW, the below text in the security consideration section reads as
> if GGSN/PGW and UE are on-link (wrt IPv6), if read together with the
> next line.

Certainly they must be on-link, can't be offlink.

Alex

>
> // 9.  Security Considerations
>
> .. ..
>
>
> and the fact that the UE and the first-hop router (PDN-GW/GGSN or
> SGW) are the only nodes on the link.  For off-link IPv6 attacks, the
> 3GPP EPS is as vulnerable as any IPv6 system.
>
>
>
> Cheers, Rajiv
>
>
>
>
> // 5.2. IPv6 Address Configuration
>
> .. ..
>
>
> In the 3GPP link model, the /64 prefix assigned to the UE cannot be
> used for on-link determination (because the L-bit in the Prefix
> Information Option (PIO) in the RA must always be set to zero). If
> the advertised prefix is used for SLAAC, then the A-bit in the PIO
> must be set to one. Details of the 3GPP link-model and address
>
>
>
>
>
>
>
> -----Original Message----- From: Cameron Byrne <[email-masked]>
> Date: Wednesday, November 21, 2012 10:47 PM To: Julien Laganier
> <[email-masked]> Cc: "[email-masked]" <[email-masked]>,
> "[email-masked]"
> <[email-masked]> Subject: Re: [v6ops] NUD
> and draft-byrne-v6ops-64share-03
>
>>> network reachability and the same address with a /64 subnet to
>>> the tethered LAN interface.The tethered LAN interface may then
>>> Now a host on the tethered LAN will configure an IPv6 address
>>> with SLAAC based on the advertized /64, and starts to use it.
>>>
>> AFAIK, the GGSN/PGW does not do NUD.  The /64 is considered
>> off-link [1] and therefore no host resolution is done
>>
>>> _______________________________________________ v6ops mailing
>>> list [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>>>

---

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

Le 29/11/2012 09:17, jouni korhonen a écrit :
>> On Sun, Nov 25, 2012 at 4:58 AM, jouni korhonen
>> <[email-masked]> wrote: Hi,
>>
>> On Sun, Nov 25, 2012 at 12:07 PM, Rajiv Asati (rajiva)
>> <[email-masked]> wrote:
>>>

Ok no NUD but yes ND - the ip-mac NS/NA resolution part.

Alex

---

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

Le 11/12/2012 22:03, Jouni Korhonen a écrit :
>> When you say that PGW/GGSN don't do NUD, are you talking about a
>> standard specification, or an implementation?
>>
>> --julien
>
> Both. For the specification part, I admit, I felt a bit uneasy with
> my statement ;) However, I do not see a reason why to do so, since
> the /64 independent of the IID gets forwarded to the UE in any case.

IT some cases it doesn't.

If the link is CDC-Ethernet (a form of 3GPP cellular long-range link,
but relying on the use of IEEE-assigned MAC addresses) then not the
entire /64 is forwarded to the UE.  There is first a NS/NA for the
address within that /64 (as we know with WiFi).  If no answer NA then
packets get dropped.

Alex

>
> - Jouni _______________________________________________ v6ops
> mailing list [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>
>

---

From: Cameron Byrne <[email-masked]>
Date: Thu, 13 Dec 2012 15:26:25 -0800

Alex,

> address within that /64 (as we know with WiFi).  If no answer NA then

As far as i know, CDC-Ethernet has nothing to do with 3GPP networks
and does not change the network operations or behavior in any way of
the network.

What i think you are describing is the USB LTE devices may present to
the host computer a CDC-Ethernet interface. These USB devices do all
manner of "interesting things" to make the host computer inter-operate
with the 3GPP network...  for example, proving a MAC address or
presenting a DHCPv6 server that appears to be coming from the the WAN
but in fact is just a function of the local USB software that extracts
things like DNS servers from the 3GPP PCO to pass on to the host that
would not otherwise be able to parse this info.

> [email-masked]

---

From: Julien Laganier <[email-masked]>
Date: Thu, 13 Dec 2012 16:55:29 -0800

On Tue, Dec 11, 2012 at 1:03 PM, Jouni Korhonen <[email-masked]>wrote:

> Both. For the specification part, I admit, I felt a bit uneasy with my
> statement ;) However, I do not see a reason why to do so, since the /64
> independent of the IID gets forwarded to the UE in any case.

I am not aware of a specification that says PGW/GGSN do not do NUD. A
reason to do so would be full compliance to RFC 4861 such that the PGW/GGSN
verify that the neighbors (i.e., the UE) it is sending packets to are
indeed reachable and not sent in a black hole. This is independent from the
forwarding / routing decision and/or address resolution.

So it seems the document should clarify that the described mechanism works
only under the assumption that PGW/GGSN do not do NUD.

--julien

---

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

Hi Cameron,

I agree with your point about CDC-Ethernet being specific to something
else than 3GPP.

But the behaviour of the 3GPP cellular link is very much different if I
open it with CDC-Ethernet, than if I do it with ppp.

This behaviour makes many statements in cellular-specific RFCs less
relevant.

Le 14/12/2012 00:26, Cameron Byrne a écrit :
>>>> When you say that PGW/GGSN don't do NUD, are you talking about
>>>> a standard specification, or an implementation?
>>>>
>>>> --julien
>>>
>>>
>>> Both. For the specification part, I admit, I felt a bit uneasy
>>> with my statement ;) However, I do not see a reason why to do
>>> so, since the /64 independent of the IID gets forwarded to the UE
>>> in any case.
>>
>>
>> If the link is CDC-Ethernet (a form of 3GPP cellular long-range
>> link, but relying on the use of IEEE-assigned MAC addresses) then
>> not the entire /64 is forwarded to the UE.  There is first a NS/NA
>> for the address within that /64 (as we know with WiFi).  If no
>> answer NA then packets get dropped.
>>
>> Alex
>>
>
> the host computer a CDC-Ethernet interface.

Yes.

> These USB devices do all manner of "interesting things" to make the
> host computer inter-operate with the 3GPP network...

YEs.  Some of these interesting things, and different from ppp, are the
following:

Contrary to setting up a connection with pppd, setting it up with
CDC-Ethernet (use e.g. 'qmi') will provoke that the Access Router sends
NS on the interface.  With pppd the AR never sends NS on the interface.

Again, contrary to pppd, the link-local address of the UE is not
enforced by the AR, but enforced by the UE.

Still contrary to pppd, the Interface ID is not enforced by AR, but
formed by the UE.

The Interface ID is formed from a central registry guaranteeing
uniqueness (as opposed to pppd generating apparently random unique ids).
  That registry is oui.txt at IEEE.

The Interface ID is formed from this oui.txt-based 'MAC' address
according to a rule (AFAIK non-std).  That rule is the following: use
the first 3 bytes of the 'MAC' address, and use the last 3 bytes as 0.
Then do the rest like in RFC2464.

> for example, proving a MAC address or presenting a DHCPv6 server that
> appears to be coming from the the WAN but in fact is just a function
> of the local USB software that extracts things like DNS servers from
> the 3GPP PCO to pass on to the host that would not otherwise be able
> to parse this info.

I could visualize this idea of an intermediate entity (the key) proving
a MAC address, something like the LTE USB key originating some ND
messaging, to make think something.

But, the src address of the NS I see is the link-local address which I
believe to belong to the Access Router in the infrastructure.  Because
that address is also the next-hop of the default route of UE.  The MAC
address in Source link-layer address of that NS is a MAC address which
is not of that LTE USB key (the MAC address of the LTE USB key is from
oui.txt and .

About presenting a DHCPv6 server - not sure it's the case here, because
we sent DHCPv6 Solicit and Informatio-Request on this interface and no
answer.  Maybe  elsewhere it does.

About extracting the DNS server from the 3GPP PCO - this is something
not done locally.  I don't know whether the network does not put that
DNS in 3GPP PCO, or that we can't extract it here. (a pppd connection on
same operator with same SIM card but with a non-CDC-Ethernet key won't
deliver the DNS server address either).

Yours,

Alex

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 14 Dec 2012 10:54:57 +0100 (CET)

On Thu, 13 Dec 2012, Julien Laganier wrote:

> reason to do so would be full compliance to RFC 4861 such that the 
> PGW/GGSN verify that the neighbors (i.e., the UE) it is sending packets 
> to are indeed reachable and not sent in a black hole. This is 
> independent from the forwarding / routing decision and/or address 
> resolution.

Would you expect a router to do NUD if it has the following configuration:

ipv6 route 2001:DB8::/64 serial1/0

As far as I can discern, this is what the SPGW does, it creates a /64 
route towards it's GTP interface, and since there is no NS being done, 
there can't be any NUD, right?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Cameron Byrne <[email-masked]>
Date: Fri, 14 Dec 2012 04:03:29 -0800

Sent from ipv6-only Android
On Dec 14, 2012 1:32 AM, "Alexandru Petrescu" <[email-masked]>
> is not of that LTE USB key (the MAC address of the LTE USB key is from

Do you have conclusive data that the ns is coming from the ggsn and not a
synthetic creation of thr key?

This data sounds circumstantial.

In any event cdc ethernet and ppp are relationships between the usb key and
the host. They are not relationships between the host and the network or
the key and the network. This relationship is unnatural and causes a lot of
issues. I agree with your point that the UE defined in my 3gpp64share draft
should explicitly expect a p2p interface.

CB

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 14 Dec 2012 14:07:46 +0100

Le 14/12/2012 13:03, Cameron Byrne a écrit :
> Sent from ipv6-only Android On Dec 14, 2012 1:32 AM, "Alexandru
> Petrescu" <[email-masked]
> <mailto:[email-masked]>> wrote:
>>
>> Hi Cameron,
>>
>> I agree with your point about CDC-Ethernet being specific to
>> something else than 3GPP.
>>
>> But the behaviour of the 3GPP cellular link is very much different
>>  if I open it with CDC-Ethernet, than if I do it with ppp.
>>
>> This behaviour makes many statements in cellular-specific RFCs
>> less relevant.
>>
>>> <[email-masked]
>>> <mailto:[email-masked]>>
> wrote:
>>>>
>>>>> On Dec 11, 2012, at 9:48 PM, Julien Laganier
>>>>> <[email-masked] <mailto:[email-masked]>>
>>>>> wrote:
>>>>>
>>>>>> When you say that PGW/GGSN don't do NUD, are you talking
>>>>>> about a standard specification, or an implementation?
>>>>>>
>>>>>> --julien
>>>>>
>>>>>
>>>>>
>>>>> Both. For the specification part, I admit, I felt a bit
>>>>> uneasy with my statement ;) However, I do not see a reason
>>>>> why to do so, since the /64 independent of the IID gets
>>>>> forwarded to the UE in any case.
>>>>
>>>>
>>>>
>>>> If the link is CDC-Ethernet (a form of 3GPP cellular
>>>> long-range link, but relying on the use of IEEE-assigned MAC
>>>> addresses) then not the entire /64 is forwarded to the UE.
>>>> There is first a NS/NA for the address within that /64 (as we
>>>> know with WiFi). If no answer NA then packets get dropped.
>>>>
>>>> Alex
>>>>
>>>
>>> As far as i know, CDC-Ethernet has nothing to do with 3GPP
>>> networks and does not change the network operations or behavior
>>> in any way of the network.
>>>
>>> What i think you are describing is the USB LTE devices may
>>> present to the host computer a CDC-Ethernet interface.
>>
>>
>> Yes.
>>
>>
>>> These USB devices do all manner of "interesting things" to make
>>> the host computer inter-operate with the 3GPP network...
>>
>>
>> YEs.  Some of these interesting things, and different from ppp, are
>> the following:
>>
>> CDC-Ethernet (use e.g. 'qmi') will provoke that the Access Router
>> sends NS on the interface.  With pppd the AR never sends NS on the
>>  interface.
>>
>> Still contrary to pppd, the Interface ID is not enforced by AR,
>> but formed by the UE.
>>
>> uniqueness (as opposed to pppd generating apparently random unique
>>  ids). That registry is oui.txt at IEEE.
>>
>> according to a rule (AFAIK non-std).  That rule is the following:
>> use the first 3 bytes of the 'MAC' address, and use the last 3
>> bytes as 0. Then do the rest like in RFC2464.
>>
>>
>>> for example, proving a MAC address or presenting a DHCPv6 server
>>>  that appears to be coming from the the WAN but in fact is just a
>>>  function of the local USB software that extracts things like DNS
>>>  servers from the 3GPP PCO to pass on to the host that would not
>>>  otherwise be able to parse this info.
>>
>>
>> I could visualize this idea of an intermediate entity (the key)
>> proving a MAC address, something like the LTE USB key originating
>> some ND messaging, to make think something.
>>
>> But, the src address of the NS I see is the link-local address
>> which I believe to belong to the Access Router in the
>> infrastructure.  Because that address is also the next-hop of the
>> default route of UE.  The MAC address in Source link-layer address
>>  of that NS is a MAC address which is not of that LTE USB key (the
>>  MAC address of the LTE USB key is from oui.txt and .
>>
>
> Do you have conclusive data that the ns is coming from the ggsn and
> not a synthetic creation of thr key?

YEs, I tend to think so.  The reasons are:

- the NS is sent when the connection is put up.
- the NS also shows up right after the UE sends a echo request.  The
   target address in NS is equal to the src of the echo request.
- the MAC address in the Source link-layer is not that of the key.
- the src address is a link-local address which is not of the key.
- the src address is the same as the default route of the UE.

There are also RAs and they seem originated by the GGSN, not by the key,
right?

Anyways, whatever 'hiding' and 'performing on behalf of' and 'proxy'
this key does, and whoever this NS sends (be it the GGSN or the key), if
I don't reply to the NS then the data packet is not delivered to me.
This means that I must run a form of proxy ND for 64share to work on
CDC-Ethernet cellular links.

> This data sounds circumstantial.

Well, yes circumstantial to some but norm to me.

> In any event cdc ethernet and ppp are relationships between the usb
> key and the host. They are not relationships between the host and the
> network or the key and the network. This relationship is unnatural
> and causes a lot of issues. I agree with your point that the UE
> defined in my 3gpp64share draft should explicitly expect a p2p
> interface.

YEs, I agree.

The ptp interface could be described.  There are pure ptp interfaces
which dont run ND and whose addresses are dictated by the network, and
there are ptp interfaces whose addresses are IEEE MAC and which run ND.

Alex

>
> CB
>
>> About presenting a DHCPv6 server - not sure it's the case here,
>> because we sent DHCPv6 Solicit and Informatio-Request on this
>> interface and no answer.  Maybe  elsewhere it does.
>>
>> About extracting the DNS server from the 3GPP PCO - this is
>> something not done locally.  I don't know whether the network does
>>  not put that DNS in 3GPP PCO, or that we can't extract it here. (a
>>  pppd connection on same operator with same SIM card but with a
>> non-CDC-Ethernet key won't deliver the DNS server address either).
>>
>> Yours,
>>
>> Alex
>>
>>
>>>>>
>>>>> mailing list [email-masked] <mailto:[email-masked]>
>>>> list [email-masked] <mailto:[email-masked]>

---

From: Jouni Korhonen <[email-masked]>
Date: Fri, 14 Dec 2012 15:39:23 +0200

> This behaviour makes many statements in cellular-specific RFCs less

Say.. if the driver and the UE misbehaves which one is to correct? The
driver & the UE or the network (and its specifications)?

- Jouni

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 14 Dec 2012 14:57:45 +0100

Le 14/12/2012 14:39, Jouni Korhonen a écrit :
> Say.. if the driver and the UE misbehaves which one is to correct?
> The driver & the UE or the network (and its specifications)?

That sounds wise and although I have a preference I wouldn't put it bluntly.

Should 64share ack the existence of cellular ptp links with IEEE MAC
addresses and ND (instead of network-dictated UE IID and noARP)?  Are
they the future of cellular links?  Or are they misbehaving?

Alex

---

From: Julien Laganier <[email-masked]>
Date: Fri, 14 Dec 2012 11:30:34 -0800

On Fri, Dec 14, 2012 at 1:54 AM, Mikael Abrahamsson <[email-masked]> wrote:
>> I am not aware of a specification that says PGW/GGSN do not do NUD. A reason to do so would be full compliance to RFC 4861 such that the PGW/GGSN verify that the neighbors (i.e., the UE) it is sending packets to are indeed reachable and not sent in a black hole. This is independent from the forwarding / routing decision and/or address resolution.
>
>
> As far as I can discern, this is what the SPGW does, it creates a /64 route towards it's GTP interface, and since there is no NS being done, there can't be any NUD, right?

I am not sure how material my expectations are to this discussion.

Reading our specifications (RFC 4861 for that matter), the fact that
the PGW/GGSN doesn't need to send NS for address resolution on the GTP
interface doesn't seem to dispense it from performing NUD:

   Neighbor Unreachability Detection is used for all paths between hosts
   and neighboring nodes, including host-to-host, host-to-router, and
   router-to-host communication.  Neighbor Unreachability Detection may
   also be used between routers, but is not required if an equivalent
   mechanism is available, for example, as part of the routing protocols.

Now I am not saying the PGW/GGSN should do NUD (this is a different
discussion); what I am saying is that given the mechanism proposed in
the draft relies on the PGW/GGSN not doing NUD, the draft should
mention that.

--julien

---

From: Jouni Korhonen <[email-masked]>
Date: Sat, 15 Dec 2012 14:23:20 +0200

> they the future of cellular links?  Or are they misbehaving?

Generally about this "topic". The 3GPP link has no link-layer addresses.
If the driver/UE goes and tries to do e.g. address resolution, something
is definitely wrong on the UE side. Some USB drivers and GGSNs try to fix
the situation and synthesise SLLAs and TLLAs into NDP messages.. just to
keep misbehaving UEs happy. It is a hack and the sustainable approach
would be fixing the UEs.

- JOuni

---

From: Jouni Korhonen <[email-masked]>
Date: Sun, 16 Dec 2012 22:09:00 +0200

> is definitely wrong on the UE side. Some USB drivers and GGSNs try to fix
                                           ^^^^^^^^^^^
Correcting myself.. modem firmwares.