Subject: Re: [v6ops] RFC 7278 on Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 17 Feb 2016 16:25:18 +0100

Hi,

I have a comment on this RFC7278.

The comment comes from the observation that the operator also uses an 
address from the 64share prefix (a global address).

As such that address too should not be used in the 'LAN'.

This may lead to several textual modifications to the document.  For 
example:
> R-2: The UE MUST defend all of its IPv6 addresses on the LAN link.

This is wrongly stated, because the UE does not own that prefix, so it 
can't say "its IPv6 addresses".  That prefix is belonging to a link not 
to the UE, because the operator also makes an address out of it.

Alex

Le 26/06/2014 22:55, [email-masked] a écrit :
> A new Request for Comments is now available in online RFC libraries.
>
>
>          RFC 7278
>
>          Title:      Extending an IPv6 /64 Prefix from
>                      a Third Generation Partnership Project (3GPP)
>                      Mobile Interface to a LAN Link
>          Author:     C. Byrne,
>                      D. Drown,
>                      A. Vizdal
>          Status:     Informational
>          Stream:     IETF
>          Date:       June 2014
>          Mailbox:    [email-masked],
>                      [email-masked],
>                      [email-masked]
>          Pages:      10
>          Characters: 19965
>          Updates/Obsoletes/SeeAlso:   None
>
>          I-D Tag:    draft-ietf-v6ops-64share-10.txt
>
>          URL:        http://www.rfc-editor.org/rfc/rfc7278.txt
>
> This document describes requirements for extending an IPv6 /64 prefix
> from a User Equipment Third Generation Partnership Project (3GPP)
> radio interface to a LAN link and describes two implementation
> examples.
>
> This document is a product of the IPv6 Operations Working Group of the IETF.
>
>
> INFORMATIONAL: This memo provides information for the Internet community.
> It does not specify an Internet standard of any kind. Distribution of
> this memo is unlimited.
>
> This announcement is sent to the IETF-Announce and rfc-dist lists.
> To subscribe or unsubscribe, see
>    http://www.ietf.org/mailman/listinfo/ietf-announce
>    http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist
>
> For searching the RFC series, see http://www.rfc-editor.org/search
> For downloading RFCs, see http://www.rfc-editor.org/rfc.html
>
> Requests for special distribution should be addressed to either the
> author of the RFC in question, or to [email-masked].  Unless
> specifically noted otherwise on the RFC itself, all RFCs are for
> unlimited distribution.
>
>
> The RFC Editor Team
> Association Management Solutions, LLC
>
>
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 17 Feb 2016 16:26:36 +0100

Hi,

Alex

---

From: Mark Smith <[email-masked]>
Date: Thu, 18 Feb 2016 06:56:43 +1100

Are you sure about that? It was my understanding that the unconventional
thing about a 3GPP setup was that all traffic to all addresses within the
/64 was (blindly) forwarded to the UE, even if the UE uses one or more of
those addresses on the end of the link. I think that is only possible
because the link is a point to point one.

(Presumably the UE has a discard route for the /64 to prevent loops for
non-existent addresses.)

> This is wrongly stated, because the UE does not own that prefix, so it
can't say "its IPv6 addresses".  That prefix is belonging to a link not to
the UE, because the operator also makes an address out of it.
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 18 Feb 2016 09:40:45 +0100

Le 17/02/2016 20:56, Mark Smith a écrit :
>
> On 18 Feb 2016 2:26 AM, "Alexandre Petrescu"
> <[email-masked] <mailto:[email-masked]>>
>  wrote:
>>
>> Hi,
>>
> Are you sure about that?

YEs.  In the UE the address of the default router is an address prefixed
by the same prefix as the prefix that the UE believes is for self (the
64share prefix).

The default router address is not a link-local address (it's a GUA),
although it could have been LL in theory.

And this time, different from my earlier experiments, the 64share
happens on the module - i.e. there is no intermediary modem like a
cellular USB dongle or something which would do things not in control,
like proxy ND or proxy DHCP.

> It was my understanding that the unconventional thing about a 3GPP
> setup was that all traffic to all addresses within the /64 was
> (blindly) forwarded to the UE, even if the UE uses one or more of
> those addresses on the end of the link. I think that is only
> possible because the link is a point to point one.

YEs, that is the case - all addresses in the prefix are forwarded to the
UE.  But I doubt the operator forwards to UE the packets addressed to
the default router.  This is something I can try and report.

(it would be strange that the packets addressed of the default router
  be forwarded to the UE, but one never knows with the ppp links).

> (Presumably the UE has a discard route for the /64 to prevent loops
> for non-existent addresses.)

YEs.  W/o 64share the UE installs a route for the /64 on its cellular
interface (a "*" route on which UE does ND).  Then when doing 64share
the UE must remove that route from the cellular interface and install it
on its other interface (USBnet in my case).  I guess this is what you
mean by discard route.

However, it must maintain on its celluar interface the default route (a
/128 host-based route).

Alex

>> This is wrongly stated, because the UE does not own that prefix,
>> so
>>
> it can't say "its IPv6 addresses".  That prefix is belonging to a
> link not to the UE, because the operator also makes an address out of
> it.
>>
>> Alex
>>
>> Le 26/06/2014 22:55, [email-masked]
> <mailto:[email-masked]> a écrit :
>>>
>>> Title:      Extending an IPv6 /64 Prefix from a Third Generation
>>>  Partnership Project (3GPP) Mobile Interface to a LAN Link
>>> Author: C. Byrne, D. Drown, A. Vizdal Status:     Informational
>>> Stream: IETF Date:       June 2014 Mailbox:
>>> [email-masked]
> <mailto:[email-masked]>,
>>> [email-masked] <mailto:[email-masked]>, [email-masked]
>>> <mailto:[email-masked]> Pages:      10 Characters:
>>> 19965 Updates/Obsoletes/SeeAlso:   None
>>>
>>> This document describes requirements for extending an IPv6 /64
>>> prefix from a User Equipment Third Generation Partnership Project
>>> (3GPP) radio interface to a LAN link and describes two
>>> implementation examples.
>>>
>>> This document is a product of the IPv6 Operations Working Group
>>> of
> the IETF.
>>>
>>>
>>> It does not specify an Internet standard of any kind.
>>> Distribution of this memo is unlimited.
>>>
>>> This announcement is sent to the IETF-Announce and rfc-dist
>>> lists. To subscribe or unsubscribe, see
>>> For searching the RFC series, see
>>> http://www.rfc-editor.org/search For downloading RFCs, see
>>> http://www.rfc-editor.org/rfc.html
>>>
>>> Requests for special distribution should be addressed to either
>>> the author of the RFC in question, or to
>>> [email-masked]
> <mailto:[email-masked]>.  Unless
>>> The RFC Editor Team Association Management Solutions, LLC
>>>
>>>
>>>
>>
>> _______________________________________________ v6ops mailing list
>> [email-masked] <mailto:[email-masked]>

---

From: Erik Kline <[email-masked]>
Date: Thu, 18 Feb 2016 18:13:02 +0900

> although it could have been LL in theory.

According to whom/what?

I have Android device on my desk with route like this:

    ::/0 -> fe80::e06f:31f4:feb2:53d6 rmnet_data0

---

From: Mark Smith <[email-masked]>
Date: Thu, 18 Feb 2016 20:50:54 +1100

> although it could have been LL in theory.

And in practice. Route next hops are supposed to be LLs except in some BGP
cases.

Share64 is based on the premise that the whole /64 is routed to the UE. I
don't know a lot about the 3GPP specs, but I presume that is what they say
is to happen.

I think the fundamental issue is that the 3GPP people decided to treat a
smartphone as special, and came up with their own ways of doing IPv6 on
them, rather than just treating the phone as nothing more than a host with
a point to point link to the network, and then just writing an IPv6 over
3GPP link RFC, and therefore supporting standard IPv6 methods for ND, RAs,
DHCPV6-PD etc. over that 3GPP link.

So whatever appears in share64 is a work around to the non-conventional
model they chose. It's going to have caveats and limitations because it
isn't conventional. If somebody does something even more unconventional
that 3GPP specs for IPv6, like a GUA router addresses rather than an LL
(which they'd have if they were using RAs, because that is what the RA RFC
says must be used) then share64 probably won't work either.

>>>> INFORMATIONAL: This memo provides information for the Internet
>>
>> community.
>>>>

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 18 Feb 2016 12:17:19 +0100

>      ::/0 -> fe80::e06f:31f4:feb2:53d6 rmnet_data0

I have Yocto device in the lab with route like this:

        ::/0 -> 2axx:xxxx:xxxx:xxxx:InterfaceID rmnet0

The forwarding flag is set.

If I reset forwarding then I get two default routes:

        ::/0 -> 2axx:xxxx:xxxx:xxxx:InterfaceID rmnet0
        ::/0 -> fe80::InterfaceID               rmnet0

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 18 Feb 2016 12:22:09 +0100

Le 18/02/2016 10:50, Mark Smith a écrit :
>
> On 18 Feb 2016 7:40 PM, "Alexandre Petrescu"
>>> <[email-masked]
>>> <mailto:[email-masked]>
> <mailto:[email-masked]
> <mailto:[email-masked]>>>
>>>
>>> wrote:
>>>>
>>>>
>>>> Hi,
>>>>
>> YEs.  In the UE the address of the default router is an address
>> prefixed by the same prefix as the prefix that the UE believes is
>> for self (the 64share prefix).
>>
>> The default router address is not a link-local address (it's a
>> GUA), although it could have been LL in theory.
>>
>
> And in practice. Route next hops are supposed to be LLs except in
> some BGP cases.

I agree that route next hops are better LLs (or ULAs) in order to save
addressing space.  I think there is a draft about this.

> Share64 is based on the premise that the whole /64 is routed to the
> UE.

Yes.

> I don't know a lot about the 3GPP specs, but I presume that is what
> they say is to happen.
>
> I think the fundamental issue is that the 3GPP people decided to
> treat a smartphone as special, and came up with their own ways of
> doing IPv6 on them, rather than just treating the phone as nothing
> more than a host with a point to point link to the network, and then
> just writing an IPv6 over 3GPP link RFC, and therefore supporting
> standard IPv6 methods for ND, RAs, DHCPV6-PD etc. over that 3GPP
> link.
>
> So whatever appears in share64 is a work around to the
> non-conventional model they chose. It's going to have caveats and
> limitations because it isn't conventional. If somebody does something
> even more unconventional that 3GPP specs for IPv6, like a GUA router
> addresses rather than an LL (which they'd have if they were using
> RAs, because that is what the RA RFC says must be used) then share64
> probably won't work either.

I can agree.

It is even worse because we can't make definitive statements whether it
will work or not.  We dont know.  In some cases the random number
generators of IP-over-USB implementations may collide with the ppp
Interface ID generators on the cellular SGSN and this may lead to
disconnections of the devices behind the UE (in the moving network) or 
of the UE altogether.

Alex

>> cellular USB dongle or something which would do things not in
>> control, like proxy ND or proxy DHCP.
>>
>>
>>> It was my understanding that the unconventional thing about a
>>> 3GPP setup was that all traffic to all addresses within the /64
>>> was (blindly) forwarded to the UE, even if the UE uses one or
>>> more of those addresses on the end of the link. I think that is
>>> only possible because the link is a point to point one.
>>
>>
>> YEs, that is the case - all addresses in the prefix are forwarded
>> to the UE.  But I doubt the operator forwards to UE the packets
>> addressed to the default router.  This is something I can try and
>> report.
>>
>> (it would be strange that the packets addressed of the default
>> router be forwarded to the UE, but one never knows with the ppp
>> links).
>>
>>
>>> (Presumably the UE has a discard route for the /64 to prevent
>>> loops for non-existent addresses.)
>>
>>
>> YEs.  W/o 64share the UE installs a route for the /64 on its
>> cellular interface (a "*" route on which UE does ND).  Then when
>> doing 64share the UE must remove that route from the cellular
>> interface and install it on its other interface (USBnet in my
>> case).  I guess this is what you mean by discard route.
>>
>> However, it must maintain on its celluar interface the default
>> route (a /128 host-based route).
>>
>> Alex
>>
>>>> This is wrongly stated, because the UE does not own that
>>>> prefix, so
>>>>
>>> it can't say "its IPv6 addresses".  That prefix is belonging to
>>> a link not to the UE, because the operator also makes an address
>>> out of it.
>>>>
>>>>
>>>> Alex
>>>>
> <mailto:[email-masked]>
>>>
>>> <mailto:[email-masked]
> <mailto:[email-masked]>> a écrit :
>>>
>>>>>
>>>>> Title:      Extending an IPv6 /64 Prefix from a Third
>>>>> Generation Partnership Project (3GPP) Mobile Interface to a
>>>>> LAN Link Author: C. Byrne, D. Drown, A. Vizdal Status:
>>>>> Informational Stream: IETF Date:       June 2014 Mailbox:
>>>>> <mailto:[email-masked]>
>>>
>>> <mailto:[email-masked]
>>> <mailto:[email-masked]>>,
>>>>>
>>>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
> <mailto:[email-masked]>>, [email-masked]
> <mailto:[email-masked]>
>>>>> <mailto:[email-masked]
>>>>> <mailto:[email-masked]>>
> Pages:      10 Characters:
>>>>>
>>>>> This document describes requirements for extending an IPv6
>>>>> /64 prefix from a User Equipment Third Generation Partnership
>>>>> Project (3GPP) radio interface to a LAN link and describes
>>>>> two implementation examples.
>>>>>
>>>>> This document is a product of the IPv6 Operations Working
>>>>> Group of
>>>
>>> the IETF.
>>>>>
>>>>>
>>>>>
>>>>> Requests for special distribution should be addressed to
>>>>> either the author of the RFC in question, or to
>>>>> [email-masked] <mailto:[email-masked]>
>>>
>>> <mailto:[email-masked]
> <mailto:[email-masked]>>.  Unless
>>>>>
>>>>> specifically noted otherwise on the RFC itself, all RFCs are
>>>>> for unlimited distribution.
>>>>>
>>>>>
>>>> _______________________________________________ v6ops mailing
>>>> list [email-masked] <mailto:[email-masked]>
>>>> <mailto:[email-masked]
> <mailto:[email-masked]>>

---

From: Gert Doering <[email-masked]>
Date: Thu, 18 Feb 2016 14:24:23 +0100

Hi,

>         ::/0 -> fe80::InterfaceID               rmnet0

This very much looks like "something in your lab setup is funny"

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 18 Feb 2016 15:32:07 +0100

> This very much looks like "something in your lab setup is funny"

It's funny because only one default route is necessary the other is 
superfluous.

But it's in yocto that funny, or maybe something in the RA the operator 
sends.

Alex

---

From: Jouni Korhonen <[email-masked]>
Date: Thu, 18 Feb 2016 07:47:08 -0800

> to the UE, because the operator also makes an address out of it.

I highly doubt it is the network side gear that acts "wrong". Get a 
capture of the traffic before it gets mangled by your USB dongle & 
driver. Those are known to do funny things.

- Jouni

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 18 Feb 2016 19:07:40 +0100

> driver. Those are known to do funny things.

As I said there is no dongle.  Or I am on the dongle if you wish.

I will get a capture soon.  What I suspect happening is the ppp software 
("cm" command) installing the LL default route and the RA installing the 
GUA default route.  But I will see more tomorrow.

Alex

Alex

---

From: Gert Doering <[email-masked]>
Date: Thu, 18 Feb 2016 20:03:19 +0100

Hi,

> GUA default route.  But I will see more tomorrow.

The whole concept of a "next hop" does not really make a sense in 3G
networks - a PDP is a point-to-point link which doesn't do ND, so "just
point into the tunnel" is what is happening behind the scenes.

Frontend implementations that pretend that this is not a PPP interface
but "some sort of lan interface with ND and next-hop relevance" are not
a problem of the standard.

Gert Doering
        -- NetMaster

---

From: Mark Smith <[email-masked]>
Date: Fri, 19 Feb 2016 06:29:34 +1100

> point into the tunnel" is what is happening behind the scenes.

Actually, I think it does, and I also think ND is necessary on a
point-to-point link.

It is common for people to think that if address 2001:db8::0/127 is
present on one end of a link, then 2001:db8::1/127 must be present on
the other end of the link. So theoretically the address at the other
end doesn't need to be discovered, and packets for 2001:db8::1 can
just be sent down the link regardless.

Is that an assumption about 2001:db8::1/127 or an absolute and
indisputable fact?

It's an assumption because it is possible and quite valid to not have
2001:db8::1/127 configured on the other end of the think, and that is
why the assumption should be tested with ND before being relied on.

Here's why it matters. The support for /127s on P2P links (RFC6164)
was advocated as fixing the ping-pong problem, but the trouble is that
it doesn't guarantee it does, because it is based on the untested
assumption that both ends of the link will be configured with the
addresses in the /127 e.g.,

A-End:
address: 2001:db8::0
route: 2001:db8::0/127 via ptp-int

B-End:
address: (not configured)
route: 2001:db8::0/127 via ptp-int
or
route: :: via ptp-int

and you have a ping-pong problem with a /127 prefix on the link.

If ND was running on that link, the presence of 2001:db8::1 at the
B-End would be tested, and if not found, traffic for that address
would be dropped as (ICMPv6) destination not found, rather than
looping until the hop count expired.

Regards,
Mark.

---

From: Jouni Korhonen <[email-masked]>
Date: Thu, 18 Feb 2016 13:08:37 -0800

> I will get a capture soon.  What I suspect happening is the ppp software

And please get the capture from the GTP-U/C tunnel & its content that 
leaves the GGSN/PGW and also from the NAS signaling that the UE 
receives. Those tell quite a bit.

- Jouni

---

From: Gert Doering <[email-masked]>
Date: Thu, 18 Feb 2016 22:47:17 +0100

Hi,

> Actually, I think it does, and I also think ND is necessary on a

There is not much to discover on a true point-to-point link without
a multiaccess link layer below - think SDH/SONET, think PPP 
encapsulation.

> just be sent down the link regardless.

A true point-to-point link does not have a "netmask" (/127) associated
with it.  It has an "this is my address", and it could have "this is
their address", or "point that range of IP addresses down the link".

Of course many operating systems require configuration of /netbits
on ptp links, so it looks like "there is a network associated with it" -
but it isn't.  It's "us" and "them", and nothing whatsoever requires
that they are part of the same network.

Especially not in IPv6 where you have fe80:: to cover negotiations 
between both sides (like, "talk OSPF to me, baby").

> Is that an assumption about 2001:db8::1/127 or an absolute and

It's an implementation peculiarity.

[..]
> looping until the hop count expired.

If ND was running on that link, you'd have ND exhaustion attacks instead,
so not much won.  Just not looping back packets that came from the ptp link
you'd send them to is a much smarter way to handle this.

Gert Doering
        -- NetMaster

---

From: Mark Smith <[email-masked]>
Date: Fri, 19 Feb 2016 10:04:05 +1100

> a multiaccess link layer below - think SDH/SONET, think PPP

Whether or not the address implied by the prefix length actually exists is
what needs to be discovered.

It is "neighbor discovery", not "neighbor link layer address discovery on
the assumption that the address always exists for links that have link
layer addresses."

> their address", or "point that range of IP addresses down the link".

A prefix length is a statement of the range of addresses that might by on
the link, and that is it. The only way to determine if an address is on the
link is to either actively probe for it (" discover " it), or to observe if
traffic comes from it.

Does a /64 prefix assignment guarantee all 2^64 addresses are present on
the link? Does a /120 assignment guarantee all 2^8 addresses are present on
the link? Does a /126 assignment guarantee all 2^2 addresses are present on
the link? None of them somehow guarantee that each address in the prefix is
configured on an interface attached to the link.

How does a /127 assignment make a guarantee about address presence that a
/64,
/120 or a /126 assignment doesn't, when the only difference is the prefix
length?

> but it isn't.

It is the convention to sign a prefix to a p2p link and to assign addresses
to both ends from the same prefix.

  It's "us" and "them", and nothing whatsoever requires
> that they are part of the same network.

Certainly, I never said it was requirement.

So you configure 2001:db8::0(/128) on your end of the link, and configure a
route for 2001:db8:1::18/128 pointing out the p2p link.

I'm lazy, and on my end of the link I don't bother to configure
2001:db8:1::18(/128).

Does an error occur telling you that I haven't? Is this an invalid scenario
(ie., a link assigned more address space than there are devices configured
with the addresses)?

> you'd send them to is a much smarter way to handle this.

A /127 without ND trades one type of attack the possibility of another. ND
on a /127 mitigates both.

Regards,
Mark.

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 19 Feb 2016 10:35:04 +0100

> receives. Those tell quite a bit.

That's going to be hard if not impossible.

The 64share technique relies on changes on only the UE.

Alex

---

From: Gert Doering <[email-masked]>
Date: Fri, 19 Feb 2016 10:44:36 +0100

Hi,

> The 64share technique relies on changes on only the UE.

Your claim that it cannot work needs backing by traces.

Gert Doering
        -- NetMaster

---

From: Gert Doering <[email-masked]>
Date: Fri, 19 Feb 2016 10:49:33 +0100

Hi,

> the assumption that the address always exists for links that have link

It is not relevant.  If I point a /64 into the p2p interface (without
specifying a gateway address, because it's point-to-point: whatever I
stuff in on my side will come out at his side) I do not care whether it's
used on-link or somewhere behind the gateway.

This is a fundamental difference between "point towards a named next-hop
router on a multiaccess network" or "point into a point-to-point interface".

And in particular in the context of this discussion it is most relevant - 
whatever address the network element on the other side of the PDP context 
has is not relevant as it is "on the other side of a point to point link",
so "point your default route towards the ptp interface, done".

If devices choose to present this as an "ethernet-style" interface, it's
an implementer's choice - but argueing that because of this, 6share
isn't going to work is a not the correct conclusion.

Gert Doering
        -- NetMaster

---

From: Jouni Korhonen <[email-masked]>
Date: Fri, 19 Feb 2016 07:53:56 -0800

> That's going to be hard if not impossible.

You need a more cooperative operator/system vendor partner ;) Anyway, 
the point being that the claims earlier in this thread are mostly 
handwaving until we actually see what goes "on wire" not what your 
application/stack/driver is made to see.

- Jouni

---

From: 神明達哉 <[email-masked]>
Date: Fri, 19 Feb 2016 09:17:05 -0800

> and you have a ping-pong problem with a /127 prefix on the link.

Probably off-topic in the context of this thread, but I'd like to make
a small correction: a ping-pong wouldn't happen in this case,
regardless of whether the address(es) from the /127 are actually
configured or not, or whether ND is performed in the link, as long as
the routers support Section 3.1 of RFC4443 correctly:

   One specific case in which a Destination Unreachable message is sent
   with a code 3 is in response to a packet received by a router from a
   point-to-point link, destined to an address within a subnet assigned
   to that same link (other than one of the receiving router's own
   addresses).  In such a case, the packet MUST NOT be forwarded back
   onto the arrival link.

--
JINMEI, Tatuya

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 19 Feb 2016 18:17:30 +0100

> application/stack/driver is made to see.

I agree.

The RA on the wire is ok - it has the src address a LL address.  So what 
goes on the wire seems to be ok (no GUA as src address).  That address 
is the next hop of a defroute and it is ok.

On another hand, the "netmgrd" daemon on this M2M module is doing 
strange things.  Some times adds one defroute (LL), other times two 
defroutes (LL+GUA).  The kernel is not adding any defroute although it 
should.

The netmgrd software is supposedly issued in the Android world, and 
subsequently ported to a yocto OS and then re-used by legato.

yocto is an open-source linux port for ARM-5 or 6 reduced computing 
platforms, among others.

The goal here is to build what may be the smallest IPv6 pure router with 
4G and USBnet interfaces.

So whoever builds the "netmgrd" software must know that a defroute is 
only one, and typically it is a LL address.

For the packet exchange on the wire for PPP - I dont have any means to 
determine whether that is ppp protocol in the first place, it may be 
something else?  If it is ppp, maybe that link-layer exchange delivers a 
GUA instead of LL for ppp to set as default route?

If that link-layer connection establishment between the module and the 
operator delivers a GUA then it should know that nobody at IETF believes 
it right for the operator to config a GUA on the PGW in the prefix 
assigned to a UE.  BEcause if it does then the UE can not safely do 
tethering.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 19 Feb 2016 18:25:24 +0100

> isn't going to work is a not the correct conclusion.

I think it is the correct conclusion.

Because if the operator self-assigns an address out of the prefix 
advertised to the UE then the UE must make sure noone in its tethered 
network uses that same address.  Such mechanism does not exist.

There is a real risk that someone in the tethered network uses same IP 
address as the address self-assigned on the PGW.  That address has an 
IID which appears to be random (it's not MAC-based, no ff:fe, no ::1, no 
::cafe).  The USBnet has no IEEE-guaranteed unique MAC addresses.  So 
someone on the USBnet may make a random IID (for privacy or other 
USB-specific reasons) which collide with an IID generated by PGW.  The 
same prefix on the PGW interface is used in the tethered network on USB.

When this collision happens the tethered device can not ping the 
Internet, which is a bad situation to be in.

Alex

---

From: Ca By <[email-masked]>
Date: Fri, 19 Feb 2016 09:58:30 -0800

> network uses that same address.  Such mechanism does not exist.
"operator self-assigns an address out of the prefix advertised to the UE"

The operator does not assign any address from that prefix assigned to the
UE.

> address as the address self-assigned on the PGW.  That address has an

The PGW does not have an address on that subnet

> USB-specific reasons) which collide with an IID generated by PGW.  The same
> prefix on the PGW interface is used in the tethered network on USB.
>
> When this collision happens the tethered device can not ping the Internet,
> which is a bad situation to be in.
>
> Alex
>
>
I believe you are chasing an implementation issues, not a standards issues.

CB

---

From: Mark Smith <[email-masked]>
Date: Sat, 20 Feb 2016 11:27:46 +1100

(Somehow it reply rather than reply all.)

---------- Forwarded message ----------
From: Mark Smith <[email-masked]>
Date: 20 February 2016 at 10:34
Subject: Re: [v6ops] RFC 7278 on Extending an IPv6 /64 Prefix from a
Third Generation Partnership Project (3GPP) Mobile Interface to a LAN
Link
To: 神明達哉 <[email-masked]>

On Feb 20, 2016 4:17 AM, "神明達哉" <[email-masked]> wrote:
>    addresses).

There is the requirement that isn't being met and that facilitates the
ping-ping pong. The receiving router does not know about the address
space on the link, as it doesn't have an address assigned to its
interface from within it, and therefore the only thing it can do is
ask the route table what to do with the packet it received, which
might mean forwarding back onto the link due to a default route.

All of these less than robust methods (i.e., /127s, or the above text)
are really just because some router vendors decided that ND wasn't
necessary on a point-to-point link, despite this text in the ND
RFC4861, which is saying that p2p links are no different to other link
types when it comes to ND:

"     point-to-point - Neighbor Discovery handles such links just like

                      multicast links.  (Multicast can be trivially

                      provided on point-to-point links, and interfaces

                      can be assigned link-local addresses.)"

Where this has crossed over into one the areas I've worked in is
providing residential IPv6 broadband over PPPoE. PPPoE is a p2p link,
so some router vendors may have decided not to implement ND on them
(or only implemented DAD, but not ND NSes for the purposes of
discovering the presence of addresses).

/127s aren't really practical because the users' CPE might not accept
the /127 mask in the RA PIO, and even if they did, for troubleshooting
purposes and to avoid imposing CPE costs for the customer, you want to
use a /64 for the PPPoE link so that they can plug a PC directly into
your service, having all 64 IID bits so that they can use e.g.,
privacy addresses.

This sort of issue needs to be watched for in the share64 scenario
too, as if the UE doesn't have a discard route for the /64 routed
towards the UE (rather than being on the link), then a ping-pong could
also happen too between the UE and the upstream gateway.

Regards,
Mark.

  In such a case, the packet MUST NOT be forwarded back

---

From: 神明達哉 <[email-masked]>
Date: Fri, 19 Feb 2016 18:00:26 -0800

At Sat, 20 Feb 2016 11:27:46 +1100,

> might mean forwarding back onto the link due to a default route.

Ah, okay, I see what you meant.  But I'd consider this case to be too
artificial:

  B-End:

and quite unlikely to happen in practice due to simple misoperation.

I see this can be a more likely scenario as an operational error,
though:

  B-End:
  route: ::/0 via ptp-int

BTW, I just realized the FreeBSD implementation of it doesn't check
the condition of "destined to an address within a subnet assigned to
that same link" part:

    if (V_ip6_sendredirects && rt->rt_ifp == m->m_pkthdr.rcvif && !srcrt &&
        (rt->rt_flags & (RTF_DYNAMIC|RTF_MODIFIED)) == 0) {
        if ((rt->rt_ifp->if_flags & IFF_POINTOPOINT) != 0) {
            /*
             * If the incoming interface is equal to the outgoing
             * one, and the link attached to the interface is
             * point-to-point, then it will be highly probable
             * that a routing loop occurs. Thus, we immediately
             * drop the packet and send an ICMPv6 error message.
             *
             * type/code is based on suggestion by Rich Draves.
             * not sure if it is the best pick.
             */
            icmp6_error(mcopy, ICMP6_DST_UNREACH,
                    ICMP6_DST_UNREACH_ADDR, 0);
            goto bad;
        }
        type = ND_REDIRECT;
    }
(see lines 427-445 of
https://github.com/freebsd/freebsd/blob/master/sys/netinet6/ip6_forward.c).

I would wonder how commercial routers (especially high-end ones for
which this protection would matter most) implement this part of the
spec.

...but I'm afraid we are now far from the original context, so I
should probably stop here or change the subject if this is deemed to
be really important.

--
JINMEI, Tatuya

---

From: Mark Smith <[email-masked]>
Date: Sat, 20 Feb 2016 14:27:42 +1100

> and quite unlikely to happen in practice due to simple misoperation.

Agree, it was more just to point out that a /127 route rather than a /127
address on the interface could also create this situation.

>   address: (not configured)

Agree. I've found it common that if things "work", then sometimes people
aren't as rigorous about detail that doesn't seem to matter. For example,
Internet access would work with the above configuration for devices on the
B end, and that might mean people forget to configure the B end /127
address that would protect against the ping-pong attack. There is
technically nothing wrong with that configuration from an IPv6 protocol
perspective, so there won't be any error messages anywhere.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sat, 20 Feb 2016 08:21:09 +0100 (CET)

> to the UE, because the operator also makes an address out of it.

Think of the GTP tunnel as a PPP link, with the entire /64 routed to it.

So yes, the UE owns the entire prefix.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Alexandre Petrescu <[email-masked]>
Date: Sat, 20 Feb 2016 11:20:29 +0100

Le 20/02/2016 08:21, Mikael Abrahamsson a écrit :
>> can't say "its IPv6 addresses".  That prefix is belonging to a link
>> not to the UE, because the operator also makes an address out of it.
>

As you say, that /64 is routed to the link, or to the GTP tunnel.

An entire /64 routed to that PPP link does not stop either ends to form 
an address out of that /64.

For example, with /127 ptp links each of the two ends always forms and 
IP address out of that /127.  So that /127 is not owned entirely by the UE.

If one wants an entire /64 routed to one UE (not to a link) it would 
have to be a route with a next-hop equal an address,
not a "* dev gtp0".  In that case, yes, and only in that case, we could 
safely assume that that entire /64 is owned by the UE.

Alex

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sat, 20 Feb 2016 11:52:18 +0100 (CET)

On Sat, 20 Feb 2016, Alexandre Petrescu wrote:

> have to be a route with a next-hop equal an address, not a "* dev gtp0". 
> In that case, yes, and only in that case, we could safely assume that 
> that entire /64 is owned by the UE.

Generally the GGSN/SPGW doesn't use any address within that /64 (not in 
the ones I have seen anyway). With IPv6 and its use of LL, there is no 
need for the SPGW to have an address within the /64. There might be a need 
for your mobile baseband device to emulate that the GGSN/SPGW would have 
an address for your host IP stack to do the right thing, but this is 
actually not how it works on the GTP layer in my experience (and I have 
actually done a non-trivial amount of GTP tracing in my days).

So you should read the 3GPP documents that controls this and point out in 
that text where it says that the SPGW/GGSN should use an address within 
the UE /64, or show GTP traces that this is the case, before saying that 
this is the way it works.

We are multiple people in here that have worked both at mobile operators 
deploying IPv6, and people with history with vendors supplying mobile data 
equipment, that have voiced our experience/views that the point you're 
raising is not based in facts. Perhaps you should give us the benefit of 
the doubt that we might be correct?

---

From: Alexandre Petrescu <[email-masked]>
Date: Sat, 20 Feb 2016 19:02:10 +0100

Le 20/02/2016 11:52, Mikael Abrahamsson a écrit :
>> have to be a route with a next-hop equal an address, not a "* dev
>> gtp0". In that case, yes, and only in that case, we could safely
>> assume that that entire /64 is owned by the UE.
>
> need for the SPGW to have an address within the /64. There might be a
> need for your mobile baseband device to emulate that the GGSN/SPGW would
> have an address for your host IP stack to do the right thing, but this
> is actually not how it works on the GTP layer in my experience (and I
> have actually done a non-trivial amount of GTP tracing in my days).
>
> So you should read the 3GPP documents that controls this and point out
> in that text where it says that the SPGW/GGSN should use an address
> within the UE /64, or show GTP traces that this is the case, before
> saying that this is the way it works.

I can agree.  I can say now there is a defroute GUA in the UE, and 
without dongle.  I can not say where it comes from.  I _suppose_ from 
the network.  May be from the netmgrd/cm behaviour but that is as hard 
to find as asking the operator to give a GGSN packet dump.

One thing I dont understand is why the network behaviour is so important 
in an RFC which actually is independent of the network: the 64share 
method is a 100% UE implementation.

> deploying IPv6, and people with history with vendors supplying mobile
> data equipment, that have voiced our experience/views that the point
> you're raising is not based in facts. Perhaps you should give us the
> benefit of the doubt that we might be correct?

Certainly.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Sat, 20 Feb 2016 19:04:24 +0100

Le 19/02/2016 18:58, Ca By a écrit :
>
>
> On Fri, Feb 19, 2016 at 9:25 AM, Alexandre Petrescu
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>
>             On 19 Feb 2016 8:47 AM, "Gert Doering" <[email-masked]
>             <mailto:[email-masked]>> wrote:
>
>
>                 Hi,
>
>     advertised to the UE then the UE must make sure noone in its
>     tethered network uses that same address.  Such mechanism does not exist.
>
>
> The operator does not assign any address from that prefix assigned to
> the UE.
>
>
>     There is a real risk that someone in the tethered network uses same
>     IP address as the address self-assigned on the PGW.  That address
>     has an
>
>
>     IID which appears to be random (it's not MAC-based, no ff:fe, no
>     ::1, no ::cafe).  The USBnet has no IEEE-guaranteed unique MAC
>     addresses.  So someone on the USBnet may make a random IID (for
>     privacy or other USB-specific reasons) which collide with an IID
>     generated by PGW.  The same prefix on the PGW interface is used in
>     the tethered network on USB.
>
> I believe you are chasing an implementation issues, not a standards issues

I can agree.  This is trying to understand netmgrd/cm software on the UE 
to see where that GUA in the defroute can come from.

But I believe this is very relevant for this RFC which is a UE RFC, not 
a network RFC.

Alex

---

From: Mark Smith <[email-masked]>
Date: Sun, 21 Feb 2016 11:49:48 +1100

>
> For example, with /127 ptp links each of the two ends always forms and IP
address out of that /127.  So that /127 is not owned entirely by the UE.
>
> If one wants an entire /64 routed to one UE (not to a link) it would have
to be a route with a next-hop equal an address,

This is an example of where treating p2p links as different creates model
of operation problems.

The trouble is,

2001:db8::/64 via p2p-link

is ambiguous.

It could be saying that the address space is assigned to the p2p-link
itself, or it could be saying the address space is behind or assigned to
the device at the other end of the link.

My interpretation, based on past Cisco router experience, is that this is a
"connected" route, and therefore the address space is assigned to the link.
ARP/ND should be triggered to addresses in that space, because the last hop
for that space has been reached.

Other people who don't have my "connected" route experience would probably
interpret it as the latter, which is also logical - if you want to state
that address space is on a link, you give the device an address in the
link, so a route pointing out a p2p link is a statement that the last hop
hasn't been reached yet.

The scenario you're describing is combining both interpretations at the
same time, which creates more issues because it isn't a clear statement of
whether the address space is on the link or behind/within the device at the
end of it - it's "both".

---

From: Gert Doering <[email-masked]>
Date: Sun, 21 Feb 2016 11:34:22 +0100

Hi,

> the device at the other end of the link.

A "link" does not have an address.  So it's either "the device on the
other end" or "something behind the device on the other end", which 
does not make a difference to the device on *this* side of the link.

"Stuff the packet into the tube, done".

> for that space has been reached.

Well, since you are referring to Cisco, your memory is not correct - a
"connected" route in Cisco lingo is a route that is configured on the
interface

  interface pos3/7
    ipv6 address 2001:db8::1/64

while a route pointing *to* an interface is just "static"

  ipv6 route 2001:db8:2::/64 pos3/7

whether or not either of them(!) triggers ARP/ND depends on whether this
is a multiaccess network or not - on POS (SDH/SONET), PPP, X.25, ATM PVC,
point-to-point links, there is no link-layer to be resolved, and thus,
neither ARP nor ND is done.

> link, so a route pointing out a p2p link is a statement that the last hop

And this is exactly how *Cisco* devices are *doing* it, unless you 
consider an ethernet segment with a route being pointed to it 
("ipv6 route ... ethernet3") where you have to do ARP/ND due to the 
multiaccess nature of ethernet, even if it would be possible to run 
as point-to-point by telling both sides' ethernet layers ("send everything 
to ff:ff:ff:ff:ff:ff" and "receive everything that comes in") - but I 
do not know any product that actually works that way.

I'm explicitely not talking "ethernet being used as point-to-point link"
because just because there are only two stations on it, it's not magically
turning into a point-to-point media.

Gert Doering
        -- NetMaster

---

From: <[email-masked]>
Date: Tue, 23 Feb 2016 08:57:11 +0100

Hello,

the /64 GUA is exclusive to the UE. The network does not have any address in the /64 GUA block allocated to the subscriber.

This link is PtP. Link-local addresses are provided by the network to both the UE and the "network end", which is the GGSN, as with any PtP link.

What you see on the mobile OS is not necessarily what is happening on the link. Modem chipsets try to translate between the Ethernet interface offered to the OS and the PtP 3GPP interface:

- MAC addresses are emulated since they are required by the Ethernet interface to the OS, but not existing on the 3GPP link
- The 3GPP link mandates that the UE uses a special link-local address which is prescribed by the network. Most OS stacks however create the link-local address on their own, therefore, the modem chipset translates between the two.
- There is no ND happening on the 3GPP link (since it is PtP); the modem chipset terminates the ND requests from the OS and responds on its own.

Holger

-- 
Holger Metschulat 
Deutsche Telekom Technik GmbH 
Heinrich-Hertz-Strasse 3-7, 64295 Darmstadt 
+49 6151 58 - 18671 (Tel.) 
+49 160 901 35443 (Mobil) 
E-Mail: [email-masked] 
http://www.telekom.de 
Erleben, was verbindet.  
Die gesetzlichen Pflichtangaben finden Sie unter: www.telekom.de/pflichtangaben-dttechnik
Große Veränderungen fangen klein an – Ressourcen schonen und nicht jede E-Mail drucken. 

-----Ursprüngliche Nachricht-----
Von: v6ops [mailto:[email-masked]] Im Auftrag von Alexandre Petrescu
Gesendet: Donnerstag, 18. Februar 2016 09:41
An: Mark Smith
Cc: v6ops list
Betreff: Re: [v6ops] RFC 7278 on Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link

> address from the 64share prefix (a global address).

YEs.  In the UE the address of the default router is an address prefixed by the same prefix as the prefix that the UE believes is for self (the 64share prefix).

The default router address is not a link-local address (it's a GUA), although it could have been LL in theory.

And this time, different from my earlier experiments, the 64share happens on the module - i.e. there is no intermediary modem like a cellular USB dongle or something which would do things not in control, like proxy ND or proxy DHCP.

> because the link is a point to point one.

YEs, that is the case - all addresses in the prefix are forwarded to the UE.  But I doubt the operator forwards to UE the packets addressed to the default router.  This is something I can try and report.

> for non-existent addresses.)

YEs.  W/o 64share the UE installs a route for the /64 on its cellular interface (a "*" route on which UE does ND).  Then when doing 64share the UE must remove that route from the cellular interface and install it on its other interface (USBnet in my case).  I guess this is what you mean by discard route.

Alex

>> This is wrongly stated, because the UE does not own that prefix, so
>>
> it can't say "its IPv6 addresses".  That prefix is belonging to a link

---

From: <[email-masked]>
Date: Tue, 23 Feb 2016 08:59:16 +0100

Hello,

... and these changes are transparent to the network.

Holger

Große Veränderungen fangen klein an - Ressourcen schonen und nicht jede E-Mail drucken. 

-----Ursprüngliche Nachricht-----
Von: v6ops [mailto:[email-masked]] Im Auftrag von Alexandre Petrescu
Gesendet: Freitag, 19. Februar 2016 10:35
An: [email-masked]
Betreff: Re: [v6ops] RFC 7278 on Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link

Alex

>
> - Jouni
>
>
>> ("cm" command) installing the LL default route and the RA installing 
>> the GUA default route.  But I will see more tomorrow.
>>
>

---

From: <[email-masked]>
Date: Tue, 23 Feb 2016 09:12:47 +0100

Hello Mark,

thanks for the clarification. I should have said, their usage does not require any changes to the network side of a 3GPP link. However, the usage of 64share can be detected.

Holger

--
Holger Metschulat
Deutsche Telekom Technik GmbH
Heinrich-Hertz-Strasse 3-7, 64295 Darmstadt
+49 6151 58 - 18671 (Tel.)
+49 160 901 35443 (Mobil)
E-Mail: [email-masked]<mailto:[email-masked]>
http://www.telekom.de
Erleben, was verbindet.
Die gesetzlichen Pflichtangaben finden Sie unter: www.telekom.de/pflichtangaben-dttechnik<http://www.telekom.de/pflichtangaben-dttechnik>
Große Veränderungen fangen klein an – Ressourcen schonen und nicht jede E-Mail drucken.

Von: Mark Smith [mailto:[email-masked]]
Gesendet: Dienstag, 23. Februar 2016 09:11
An: Metschulat, Holger
Cc: Alexandre Petrescu; v6ops list
Betreff: Re: [v6ops] RFC 7278 on Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link

> ... and these changes are transparent to the network.

Not if you can detect them, by, for example, crypto or other failures.

They're better described as "translucent".

> E-Mail: [email-masked]<mailto:[email-masked]>
> http://www.telekom.de
> Erleben, was verbindet.
> Die gesetzlichen Pflichtangaben finden Sie unter: www.telekom.de/pflichtangaben-dttechnik<http://www.telekom.de/pflichtangaben-dttechnik>
> Von: v6ops [mailto:[email-masked]<mailto:[email-masked]>] Im Auftrag von Alexandre Petrescu
> An: [email-masked]<mailto:[email-masked]>
> > [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

---

From: Mark Smith <[email-masked]>
Date: Tue, 23 Feb 2016 19:10:40 +1100

> Betreff: Re: [v6ops] RFC 7278 on Extending an IPv6 /64 Prefix from a
Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link

---

From: Mark Smith <[email-masked]>
Date: Tue, 23 Feb 2016 19:53:00 +1100

On 23 Feb 2016 7:12 PM, <[email-masked]> wrote:
>
> Hello Mark,
>
>
>
> thanks for the clarification. I should have said, their usage does not
require any changes to the network side of a 3GPP link. However, the usage
of 64share can be detected.

That may have sounded a bit snarky, however I've experienced enough
"transparent" devices that I'd prefer to call them what they actually are -
translucent. You can see through them, but they aren't actually transparent.

Regards,
Mark.

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 23 Feb 2016 16:02:33 +0100

Le 23/02/2016 08:57, [email-masked] a écrit :
> Hello,
>
> the /64 GUA is exclusive to the UE. The network does not have any
> address in the /64 GUA block allocated to the subscriber.
>
> This link is PtP. Link-local addresses are provided by the network to
> both the UE and the "network end", which is the GGSN, as with any PtP
> link.
>
> What you see on the mobile OS is not necessarily what is happening on
> the link. Modem chipsets try to translate between the Ethernet
> interface offered to the OS and the PtP 3GPP interface:
>
> - MAC addresses are emulated since they are required by the Ethernet
>  interface to the OS,

In many cases the MAC addresses are emulated, but some are more emulated
than others.

For example, some LTE User Equipment generates the entire MAC address in
a pure random manner (e.g. sierra) whereas other UEs have the first
three bytes of that MAC address centrally allocated by IEEE (e.g.
qualcomm) and the last 3 bytes 0.

> but not existing on the 3GPP link

Are MAC addresses absent from both 3G and 4G?

I am asking because I find it strange for these large companies like
qualcomm and huawei who produce chipsets for the 4G devices (but not
wifi devices) to reserve (pay) OUIs at IEEE if it were not for an
intention to use MAC addresses on the cellular link.

> - The 3GPP link mandates that the UE uses a special link-local
> address which is prescribed by the network. Most OS stacks however
> create the link-local address on their own, therefore, the modem
> chipset translates between the two.

I am not sure what you mean by modem chipset, but I am talking about a
"module" which has everything inside a large chip.  It's not like the
laptop computer on which one plugs a USB dongle containing a modem.

> - There is no ND happening on the 3GPP link (since it is PtP)

On other Point-to-Point links there is very well ND happening.  A point
to point link using a tunnel interface has ND running on it ok (e.g.
IPv6-in-IPv4 tunnel, or VPN tunnel, or MR-HA tunnel).

> the modem chipset terminates the ND requests from the OS and
> responds on its own.

I think I need to better understand the interaction between "OS" and
"modem chipset".

But I would like to suggest that 3GPP specs could take advantage from
using directly ND on the not-so-ptp links, and use unique MAC addresses
as allocated by IEEE.  For example, 3GPP could make LTE-D2D more real by
relying on these MAC and ND concepts.

Alex