Re: [v6ops] [*SPAM* Score/Req: 3.9/3.3] Re: [*SPAM* Score/Req: 3.9/3.3] Re: reclassify 464XLAT as standard instead of info

[Alexandre Petrescu <[e-mail]>]

Le 21/09/2017 à 15:56, Mikael Abrahamsson a écrit :
> On Thu, 21 Sep 2017, Alexandre Petrescu wrote:
> 
>> Ok, I can agree if you say so.  I can not capture packets on the UE to 
>> confirm or infirm; the "UE" is the "modem", that's how Balong calls 
>> it; there is no source code for that part.
>>
>> It seems that you tried to capture on modem?  Or is it that somebody 
>> told this to you?  Or is it that it is in the 3GPP specs?
> 
> It's in the 3GPP spec. In 3G it's GTP GGSN-RNC, and then it's handled by 
> the RLC layer between RNC and UE. I'd imagine it's something similar in 
> LTE but then instead between UE and eNodB (since there is no RNC).

So you mean the UE does GTP?

(Mr. Byrne and another person said that GTP is not run in the UE.)

But has one tried it?

I am asking you because of this: the 3GPP and IETF specs say that DHCPv6 
should run on the Client and on the Server.  There is no notion of 
"proxy DHCP".  Yet modems do just that: some run DHCPv6, some block 
DHCPv6 - all non-standard ways of DHCP.  They are like middle-boxes, 
trying to be transparent.

By this logic, could it be that some modem implements also GTP?

>> The doubt I have is the following: operator tells that the Terminal 
>> does some form of connection setup.  I dont see it.  Operator does not 
>> see it
>>  either.  I speculate that that connection setup includes GTP.  It's a 
>> speculation.
>>
>> I do see packets on PGW that show IPv6 encapsulated in GTP (an IPv4 
>> protocol).
> 
> GTP can be either IPv4 or IPv6, and the encapsulated packets can be 
> either IPv4 or IPv6 (and probably other protocols as well, I haven't 
> used it for anything else).

When I read that, I wonder whether it is better to encapsulate IPv6 in 
GTP-that-uses-IPv6addresses-as-src-and-dst?

Alex

--- Begin Message ---

response inline

Ales


> -----Original Message-----
> From: Alexandre Petrescu [mailto:[e-mail]]
> Sent: Friday, July 14, 2017 9:50 PM
> To: Vízdal Aleš <[e-mail]>
> Cc: Ted Lemon <[e-mail]>; dhcwg <[e-mail]>; Bernie Volz
> (volz) <[e-mail]>
> Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis-09.txt - questions
> about Solicit Prefix Delegation
>
>
>
> Le 14/07/2017 à 21:26, Vízdal Aleš a écrit :
> >
> >
> >> On 14 Jul 2017, at 21:15, Alexandre Petrescu
> >> <[e-mail]> wrote:
> >>
> >>> Le 14/07/2017 à 20:35, Ted Lemon a écrit : So are the DHCP clients
> >>> you are talking about setting the IP header hop count to
> >>>  0/1, or the DHCP header hop-count field to 0/1?   That is, what
> >>>  is the behavior you are concerned about, and why do you think it
> >>> might cause a problem in this case?
> >>
> >> Some clients I am talking about issue DHCP Solicit with Hop Limit
> >> field in the IPv6 base header (not DHCP UDP header) with value 1.
> >>
> >> This Solicit is sent on a cellular network.  The cellular network
> >> encapsulates at some point in IPv4, and further decapsulates.  The
> >> encapsulation protocol is called "GTPU" by some non-wireshark packet
> >> dump format, with fields like "TEID", "GTP_TPDU_MSG".  This  cellular
> >> network does not offer IPv4 access to end user, it only offers IPv6.
> >>
> >> There is no GTP RFC.
> >
> > GTP aka GPRS Tunnelling Protocol has been specified by 3GPP.
> >
> > It starts at the eNodeB and terminates at the PGW where the DHCP
> > server/relay would sit.
>
> You see, I am also told that my "MT" ("Mobile Terminal"?) terminates GTP.  I
> guess both are possible (terminate some times at eNodeB and other times at
> MT).

I can only recommend checking the 3GPP technical specification dealing with the architecture and protocol details.
Google will help.

> Or otherwise the expression "terminate at" may have different meanings to
> different people.
>
> >> There is an RFC for "Generic Packet Tunnelling in IPv6".  This RFC
> >> says that encap/decap decrements the Hop Limit.
> >>
> >> This raises a potential speculation that the network drops an
> >> incoming packet that has Hop Limit 1.
> >>
> >> It may be that the GTP encapsulation (no RFC) does not decrement the
> >> Hop Limit of a packet-to-be-encapsulated.  In this case there is no
> >> problem with DHCP Solicit having Hop Limit 1.
> >
> > It shall keep the packet as-is, since it is not visible from
> > user/data-plane point of view.
>
> I dont understand that.  Not sure what you mean by user-data planes.

You can imagine that your IP traffic (originated by the UE or devices behind the UE) is a payload to the Mobile Network.
It is received on the radio interface of the eNodeB that puts the packet into the GTP, there is no routing involved.
In other words, your UE is assigned an IP address / IPv6 prefix, the L3 next hop is the GGSN/PGW, so any other node between
your UE and the GGSN/PGW does not change the packet as it forwards based on the GTP header.

> The IP Hop Limit is in the IP header.  Some IP tunnelling mechanisms do touch
> the Hop Limit of the encapsulated packet.  Why would GTP be different than
> the other IP tunnelling mechanisms?

As stated above, there is no routing involved. What is received on the radio interface is encapsulated into GTP and forwarded towards the GGSN/PGW.

> > I suggest a deep dive into 3GPP specs ...
>
> It is certainly advantageous to understand the 3GPP specs.

It is key to understand the architecture ...

> But I'd rather consider putting that into an Internet Draft.

Not sure if recasting 3GPP, ETSI, BBF and other specs as ID's would help.

> Alex
>
> >
> >> Alex
> >>
> >>
> >>
> >>> On Fri, Jul 14, 2017 at 8:32 PM, Alexandre Petrescu
> >>> <[e-mail] <mailto:[e-mail]>>
> >>> wrote: Le 13/07/2017 à 23:14, Ted Lemon a écrit : On Jul 13, 2017
> >>> 16:01, "Alexandre Petrescu" <[e-mail]
> >>> <mailto:[e-mail]>
> >>> <mailto:[e-mail]
> >>> <mailto:[e-mail]>>> wrote: My oppinion is to
> >>> make DHCP spec Hop Limit > 1.  In order to make sure that the
> >>> encap/decap of DHCP Solicit in IPv4 GTP happening on a cellular link
> >>> does not drop it to 0 upon decap. If a link local sourced multicast
> >>> with a hop limit of one is dropped between sender and receiver, ip
> >>> is broken on that link, ne c'est pas? If that link is a real link
> >>> then yes - ip is broken on that link. But if the link is a virtual
> >>> link - like when on a tunnel - then it may be that tunnel works or
> >>> no. Alex
> >>
> >> _______________________________________________ dhcwg mailing list
> >> [e-mail] https://www.ietf.org/mailman/listinfo/dhcwg
> >
> > Zásady komunikace, které společnost T-Mobile Czech Republic a.s.
> > užívá při sjednávání smluv, jsou uvedeny
> > zde<http://www.t-
> mobile.cz/dcpublic/Zasady_komunikace_pri_sjednavani_smluv_cz.pdf>.
> >
> >
> >
> Není-li v zásadách uvedeno jinak, nepředstavuje tato zpráva konečný
> > návrh na uzavření či změnu smlouvy ani přijetí takového návrhu. The
> > communication principles which T-Mobile Czech Republic a.s. applies
> > when negotiating contracts are defined
> > here<http://www.t-
> mobile.cz/dcpublic/Zasady_komunikace_pri_sjednavani_smluv_en.pdf>.
> >
> >
> >
> Unless otherwise stated in the principles, this message does not
> > constitute the final offer to contract or an amendment of a contract
> > or acceptance of such offer.
> >

Zásady komunikace, které společnost T-Mobile Czech Republic a.s. užívá při sjednávání smluv, jsou uvedeny zde<http://www.t-mobile.cz/dcpublic/Zasady_komunikace_pri_sjednavani_smluv_cz.pdf>. Není-li v zásadách uvedeno jinak, nepředstavuje tato zpráva konečný návrh na uzavření či změnu smlouvy ani přijetí takového návrhu. The communication principles which T-Mobile Czech Republic a.s. applies when negotiating contracts are defined here<http://www.t-mobile.cz/dcpublic/Zasady_komunikace_pri_sjednavani_smluv_en.pdf>. Unless otherwise stated in the principles, this message does not constitute the final offer to contract or an amendment of a contract or acceptance of such offer.

--- End Message ---