https://osmocom.org/https://osmocom.org/favicon.ico?16647414092017-08-02T12:22:04ZOpen Source Mobile CommunicationsOsmoGGSN (former OpenGGSN) - Feature #2418: IPv6 PDP context supporthttps://osmocom.org/issues/2418?journal_id=47982017-08-02T12:22:04Zlaforge
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>In Progress</i></li><li><strong>Assignee</strong> changed from <i>dexter</i> to <i>laforge</i></li></ul><p>the patch is against a >= 10 years old openggsn version, will require lots of manual porting work :/</p> OsmoGGSN (former OpenGGSN) - Feature #2418: IPv6 PDP context supporthttps://osmocom.org/issues/2418?journal_id=48082017-08-02T23:37:50Zlaforge
<ul><li><strong>% Done</strong> changed from <i>0</i> to <i>70</i></li></ul><pre>
remote: https://gerrit.osmocom.org/3403 ippool: Add IPv6 support to IP pool implementation
remote: https://gerrit.osmocom.org/3404 lib/tun.h: Remove non-endian-safe redefinition of IP header
remote: https://gerrit.osmocom.org/3405 ippool_new(): const-ify input arguments
remote: https://gerrit.osmocom.org/3406 IPv6 support for user IP
remote: https://gerrit.osmocom.org/3407 ggsn: Send proper errors in create_context_ind()
remote: https://gerrit.osmocom.org/3408 Support setting TUN device IPv6 address + prefix
</pre> OsmoGGSN (former OpenGGSN) - Feature #2418: IPv6 PDP context supporthttps://osmocom.org/issues/2418?journal_id=48102017-08-03T12:30:53Zdexter
<ul><li><strong>File</strong> <a href="/attachments/2734">ipv6_pdp_context_reject.pcapng</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/2734/ipv6_pdp_context_reject.pcapng">ipv6_pdp_context_reject.pcapng</a> added</li></ul><p>I have configured the ggsn as suggested in:<br /><a class="external" href="http://lists.osmocom.org/pipermail/osmocom-net-gprs/2017-August/000928.html">http://lists.osmocom.org/pipermail/osmocom-net-gprs/2017-August/000928.html</a></p>
<pre>
debug
fg
listen 127.0.0.1
net 2001:780:44:2000:0:0:0:0/120
</pre>
<p>First I expected a problem with the sgsn, since this is the untested component,<br />but it may also be a problem with the ggsn as well. The debug output of<br />openggsn shows:</p>
<pre>
<0000> ippool.c:454 MS requested unsupported PDP context type
<0002> ggsn.c:202 Cannot allocate IP address in pool
</pre>
<p>This means that the ggsn is the entity that rejects the pdp context.<br />The attached trace also confirms that.</p>
<p>The sgsn log also displays the reject:</p>
<pre>
<000f> gprs_sgsn.c:898 Checking for inactive LLMEs, time = 52892
<0011> gprs_bssgp.c:789 BSSGP BVCI=2 Rx Flow Control BVC
<0010> gprs_ns.c:614 NSEI=101 Timer expired in mode tns-test (30 seconds)
<0010> gprs_ns.c:547 NSEI=101 Tx NS ALIVE (NSVCI=101)
<0010> gprs_ns.c:586 NSEI=101 Starting timer in mode tns-alive (3 seconds)
<0010> gprs_ns.c:586 NSEI=101 Starting timer in mode tns-test (30 seconds)
<0010> gprs_ns.c:560 NSEI=101 Tx NS ALIVE_ACK (NSVCI=101)
<0011> gprs_bssgp.c:789 BSSGP BVCI=2 Rx Flow Control BVC
<0011> gprs_bssgp.c:379 BSSGP TLLI=0xa1df35c3 Rx UPLINK-UNITDATA
<0012> gprs_llc.c:522 LLC RX: unknown TLLI 0xa1df35c3, creating LLME on the fly
<0012> gprs_llc_parse.c:82 LLC SAPI=1 C U GEA0 IOV-UI=0x000000 FCS=0xb9e3eb CMD=UI DATA
<0002> gprs_gmm.c:1241 MM(---/ffffffff) -> GMM ATTACH REQUEST MI(3789501891) type="GPRS attach"
<0002> gprs_sgsn.c:231 MM(/00000000) Allocated with GEA0 cipher.
<0002> gprs_gmm.c:546 MM(/c6babf03) <- GPRS IDENTITY REQUEST: mi_type=IMEI
<0011> gprs_bssgp.c:379 BSSGP TLLI=0xa1df35c3 Rx UPLINK-UNITDATA
<0012> gprs_llc_parse.c:82 LLC SAPI=1 C U GEA0 IOV-UI=0x000000 FCS=0x41d70b CMD=UI DATA
<0002> gprs_gmm.c:1180 MM(/c6babf03) -> GMM IDENTITY RESPONSE: MI(IMEI)=354391077046600
<0002> gprs_gmm.c:546 MM(/c6babf03) <- GPRS IDENTITY REQUEST: mi_type=IMSI
<0011> gprs_bssgp.c:379 BSSGP TLLI=0xa1df35c3 Rx UPLINK-UNITDATA
<0012> gprs_llc_parse.c:82 LLC SAPI=1 C U GEA0 IOV-UI=0x000000 FCS=0x00e248 CMD=UI DATA
<0002> gprs_gmm.c:1180 MM(/c6babf03) -> GMM IDENTITY RESPONSE: MI(IMSI)=001010000000102
<0002> sgsn_auth.c:160 MM(001010000000102/c6babf03) Requesting authorization
<0002> sgsn_auth.c:219 MM(001010000000102/c6babf03) Updating authorization (unknown -> accepted)
<0002> sgsn_auth.c:248 MM(001010000000102/c6babf03) Got authorization update: state unknown -> accepted
<0002> gprs_gmm.c:1104 MM(001010000000102/c6babf03) Authorized, continuing procedure, IMSI=001010000000102
<0002> gprs_gmm.c:427 MM(001010000000102/c6babf03) <- GPRS ATTACH ACCEPT (new P-TMSI=0xc6babf03)
<0011> gprs_bssgp.c:379 BSSGP TLLI=0xc6babf03 Rx UPLINK-UNITDATA
<0012> gprs_llc_parse.c:82 LLC SAPI=1 C U GEA0 IOV-UI=0x000000 FCS=0xea1c55 CMD=UI DATA
<0002> gprs_gmm.c:1998 MM(001010000000102/c6babf03) -> ATTACH COMPLETE
<0002> gprs_gmm.c:170 MM(001010000000102/c6babf03) Changing MM state from MM IDLE to MM READY
<0011> gprs_bssgp.c:379 BSSGP TLLI=0xc6babf03 Rx UPLINK-UNITDATA
<0012> gprs_llc_parse.c:82 LLC SAPI=1 C U GEA0 IOV-UI=0x000000 FCS=0x1a0d86 CMD=UI DATA
<0002> gprs_gmm.c:2442 MM(001010000000102/c6babf03) -> ACTIVATE PDP CONTEXT REQ: SAPI=3 NSAPI=5 IETF IPv6
<0002> gprs_sgsn.c:862 MM(001010000000102/c6babf03) Found GGSN 0 for APN 'internet' (requested 'internet')
<0002> gprs_gmm.c:2329 MM(001010000000102/c6babf03) Using GGSN 0
<000f> sgsn_libgtp.c:148 Create PDP Context
<0025> pdp.c:215 Begin pdp_tidset tid = 5201000000010100
<0025> pdp.c:224 End pdp_tidset
<000f> sgsn_libgtp.c:594 libgtp cb_conf(type=16, cause=220, pdp=0x7f6616bfe320, cbp=0x55fde5d3dcd0)
<000f> sgsn_libgtp.c:369 PDP(001010000000102/0) Received CREATE PDP CTX CONF, cause=220(Unknown PDP address or PDP type)
<0025> pdp.c:233 Begin pdp_tiddel tid = 5201000000010100
<0025> pdp.c:240 End pdp_tiddel: PDP found
<0002> gprs_gmm.c:2255 MM(001010000000102/c6babf03) <- ACTIVATE PDP CONTEXT REJ(cause=28)
<0011> gprs_bssgp.c:789 BSSGP BVCI=2 Rx Flow Control BVC
</pre>
<p>I wonder what could be wrong here. I have tried the sgsn emulator, but I can<br />only get it to a point where it requests an IPV4 pdp context (which also<br />gets rejected, which is expected with the current configuration). I start<br />sgsnemu as follows:</p>
<pre>
./sgsnemu --l 127.0.0.2 -r 127.0.0.1
</pre>
<p>Maybe there is commandline argument missing. commandline argument?</p>
<p>I suspect either a problem with my ggsn configuration. It might also be that<br />the pdp context request that the sgsn generates might have some issues.</p> OsmoGGSN (former OpenGGSN) - Feature #2418: IPv6 PDP context supporthttps://osmocom.org/issues/2418?journal_id=48112017-08-03T22:41:14Zlaforge
<ul></ul><p>It was working once but I broke it later in some cleanup :/</p>
<p>I've just (force-)pushed a fix to laforge/ipv6, please retry using the new version.</p>
<p>The v6 activation has now been tested against my brand-new TTCN-3 testcase for<br />PDP context activation, which supports both v4 and v6 contexts. I'll expand on this<br />and hopefully we can integrate this with Jenkins soon.</p>
<p>Regards,<br /> Harald</p> OsmoGGSN (former OpenGGSN) - Feature #2418: IPv6 PDP context supporthttps://osmocom.org/issues/2418?journal_id=48122017-08-04T17:39:20Zdexter
<ul><li><strong>File</strong> <a href="/attachments/2735">trace_v6pdpctx_act_and_deact_04072017.tar</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/2735/trace_v6pdpctx_act_and_deact_04072017.tar">trace_v6pdpctx_act_and_deact_04072017.tar</a> added</li></ul><p>I gave it another try. I have tested it with IPV4 and IPV6. For IPV4 everything<br />is fine so far. But IPV6 seems not to work.</p>
<p>The IPV6 pdpd context is successfully established, but it is not possible to<br />transfer any data. I would have expected that at least pinging the phone is<br />possible. There is data flowing between the phone and the network, but as<br />I can see so far by the log its only Rx UPLINK-UNITDATA. There is no TX data.</p>
<p>On the tun0 interface, as well as on the GTP link, the only messages that<br />appear are Router Solicitation and Neighbor Solicitation. When I look at<br />the GB interface I see the messages there as well, so these messages seem<br />to be mobile originated. However, I do not understand why source and<br />destination address is does not fall in the assigned range. When I look<br />at the pdp context ack. I can see the expected address is assigned.</p>
<p>The bahviour is cyclic, the phone establishes a pdp context, for a short time,<br />data is transfered. Then the pdp context is deactivated. After some time the<br />same happens again.</p>
<p>I have also checked with the communicator again. The communicator now shows<br />also the same behaviour. I also tried with a qualcomm modem. The same there<br />too.</p>
<p>Trades, logs and configs can be found in:<br />trace_v6pdpctx_act_and_deact_04072017.tar</p>
<p>regards,<br />Philipp</p> OsmoGGSN (former OpenGGSN) - Feature #2418: IPv6 PDP context supporthttps://osmocom.org/issues/2418?journal_id=48132017-08-05T09:15:17Zlaforge
<ul></ul><p>It's good to see that the signaling plane seems to work end-to-end, i.e.<br />the v6 PDP context is established successfully and a dynamic IPv6 address<br />is allocated.</p>
<p>The only odd part I can see on the signaling/control plane is the fact that<br />the PCO contain 0.0.0.0 as DNS server IP adresses. This is odd in two ways:</p>
<p>a) if there are no DNS servers, why report 0.0.0.0 instead of simply not<br />sending any DNS Server PCO back to the MS<br />b) if the PDP context is IPv6, the DNS Server addresses inherently also must<br />be IPv6. The MS has no way to talk to an IPv4 DNS server if it has an<br />IPv6 (only) PDP context</p>
<p>The MS then subsequently sends router and neighbor discovery requests which are<br />unanswered. The big question is how that is supposed to work on a point-to-point<br />interface anyway. In IPv4 there is no broadcast/ARP involved on such interfaces.</p>
<p>I'll read up with the relevant specs and will extend the TTCN-3 tests to transmit<br />the exact same router and neighbor discovery reqests to be able to develop<br />and test without having to set up the entire cellular network + phone for each<br />attempt.</p> OsmoGGSN (former OpenGGSN) - Feature #2418: IPv6 PDP context supporthttps://osmocom.org/issues/2418?journal_id=48142017-08-05T15:15:14Zlaforge
<ul></ul><p>Ok, I found Section 11.2.1.3.2 of 3GPP TS 29.061 which details the process. For some<br />strange reason, they decided to make it significantly more complex than in the IPv4<br />case, while at the same time making it not entirely compatible/compliant with what<br />IETF IPv6 usually does.</p>
<p>Other apparently related documents: RFC3314, RFC7066, RFC6459, TS 23.060 9.2.1</p>
<p>My understanding at this point:</p>
<ul>
<li>the IPv6 address sent in the EUA IE of the PDP CTX ACT ACK from the GGSN<br />is not used for actual traffic, but is only used for allocating an <br />"interface identifier" to the MS/UE. This "interface identifier" is<br />formed from the lower 64 bits of the prefix, while the upper 64 bits<br />are being discarded.</li>
</ul>
<ul>
<li>the MS/UE uses RFC2373 Section 2.5.8 to construct a link-local unicast<br />address from this "interface identifier". This means:
* lower 64 bits are the "interface identifier"
* upper 64 bits are fe80:0000:0000:0000</li>
</ul>
<ul>
<li>the MS may send a "router solicitation" icmpv6 message to trigger the GGSN<br />to send a router advertisement to the MS (optional!)</li>
</ul>
<ul>
<li>The GGSN sends a Router Advertisement message. The Router<br />Advertisement messages shall contain the same prefix as the one<br />provided in the PDP CTX ACT ACK. A given prefix shall not be<br />advertised on more than one PDP context on a given APN, or set of<br />APNs, within the same addressing scope. The GGSN shall be configured<br />to advertise only one prefix per PDP context.</li>
</ul>
<ul>
<li>After the MS has received the Router Advertisement message, it<br />constructs its full IPv6 address by concatenating the interface<br />identifier received in PDP CTX ACT ACK, or a locally generated interface<br />identifier, and the prefix received in the Router Advertisement. If<br />the Router Advertisement contains more than one prefix option, the MS<br />shall only consider the first one and silently discard the others.</li>
</ul>
<ul>
<li>Because any prefix that the GGSN advertises in a PDP context is unique<br />within the scope of the prefix (i.e. site- local or global), there is<br />no need for the MS to perform Duplicate Address Detection for this<br />IPv6 address. Therefore, the GGSN shall silently discard Neighbor<br />Solicitation messages that the MS may send to perform Duplicate<br />Address Detection.</li>
</ul>
<ul>
<li>It is possible for the MS to perform Neighbor Unreachability Detection<br />towards the GGSN, as defined in RFC 2461<sup><a href="#fn71">71</a></sup>; therefore if the GGSN<br />receives a Neighbor Solicitation as part of this procedure, the GGSN<br />shall provide a Neighbor Advertisement as described in RFC 2461.</li>
</ul>
<p>So now we know we need to implement router advertisements inside the<br />GGSN before we can proceed...</p> OsmoGGSN (former OpenGGSN) - Feature #2418: IPv6 PDP context supporthttps://osmocom.org/issues/2418?journal_id=49082017-08-09T08:17:05Zlaforge
<ul><li><strong>File</strong> <a href="/attachments/2737">v6.conf</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/2737/v6.conf">v6.conf</a> added</li><li><strong>Assignee</strong> changed from <i>laforge</i> to <i>dexter</i></li></ul><p>Hi Philipp,</p>
<p>it <strong>should</strong> be working now, at least more than before. In my test case, I can now see a seemingly-valid router advertiement in response to the routeer solicitation. Could you give current laforge/ipv6 another [quick] try, please?</p>
<p>My ggsn config file is attached. The important part is to have a pool with a prefix <strong>shorter</strong> than 64 bits, i.e. something like /56, so you have 256 prefixes that can be allocated to individual MSs.</p> OsmoGGSN (former OpenGGSN) - Feature #2418: IPv6 PDP context supporthttps://osmocom.org/issues/2418?journal_id=49092017-08-09T10:53:24Zdexter
<ul><li><strong>File</strong> <a href="/attachments/2738">trace_v6pdpctx_act_and_deact_09082017.tar</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/2738/trace_v6pdpctx_act_and_deact_09082017.tar">trace_v6pdpctx_act_and_deact_09082017.tar</a> added</li></ul><p>Hello Harald,</p>
<p>I have tried it again. I can see the router advertisements going up the gb interface. However, the pdp context still closes after a few seconds. I have attached the archive with the logs and the config files.</p>
<p>regards.<br />Philipp</p> OsmoGGSN (former OpenGGSN) - Feature #2418: IPv6 PDP context supporthttps://osmocom.org/issues/2418?journal_id=49112017-08-09T12:15:06Zlaforge
<ul></ul><p>Hi Philipp,</p>
<p>On Wed, Aug 09, 2017 at 10:53:24AM +0000, dexter [REDMINE] wrote:</p>
<blockquote>
<p>I have tried it again. I can see the router advertisements going up the gb interface. However, the pdp context still closes after a few seconds. I have attached the archive with the logs and the config files.</p>
</blockquote>
<p>Ok, it seems the MS needs to do neighbor solicitation after the router advertisement.<br />I'll investigate. Meanwhile I've also found+charged some phones using which I should<br />hopefully be able to test myself.</p> OsmoGGSN (former OpenGGSN) - Feature #2418: IPv6 PDP context supporthttps://osmocom.org/issues/2418?journal_id=49132017-08-09T20:50:12Zlaforge
<ul><li><strong>% Done</strong> changed from <i>70</i> to <i>80</i></li></ul><p>So, finally progress. I could make the current "laforge/ipv6" brnach work with my Fairpohne2: It establishes the v6 PDP context successfully, gets through PDP context activation and router solicitation/advertisement and then succcessfully establishes bi-directional TCP traffic to the public IPv6 internet.</p>
Chagnes compared to yesterday's version were:
<ul>
<li>implement PCO for IPv6 DNS server address assignment</li>
<li>fix some bits in router advertisement message that were not in-line with 3GPP requirements (L/A bit)</li>
<li>make sure that the upper 64bit of the EUA in the PDP Context Establishment matches the /64 prefix of the router advertisement that follows</li>
</ul>
<p>Philip: Please reproduce locally with your phone(s) and confirm it works for you, too</p> OsmoGGSN (former OpenGGSN) - Feature #2418: IPv6 PDP context supporthttps://osmocom.org/issues/2418?journal_id=49152017-08-10T09:39:21Zdexter
<ul><li><strong>File</strong> <a href="/attachments/2739">trace_ipv6_test_android_10082017.pcapng</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/2739/trace_ipv6_test_android_10082017.pcapng">trace_ipv6_test_android_10082017.pcapng</a> added</li><li><strong>File</strong> <a href="/attachments/2740">trace_ipv6_test_nokiaE90_10082017.pcapng</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/2740/trace_ipv6_test_nokiaE90_10082017.pcapng">trace_ipv6_test_nokiaE90_10082017.pcapng</a> added</li></ul><p>Attached the traces of the recent tests.</p>
<ul>
<li>Android: PDP context still closes immediately, but rest looks good. We suspect that the pdp context is closed because the DNS server is unreachable from the test host.</li>
<li>nokiaE90: PDP context stays open until it is manually closed by the user.</li>
</ul> OsmoGGSN (former OpenGGSN) - Feature #2418: IPv6 PDP context supporthttps://osmocom.org/issues/2418?journal_id=49492017-08-12T20:48:35Zlaforge
<ul><li><strong>Status</strong> changed from <i>In Progress</i> to <i>Closed</i></li><li><strong>% Done</strong> changed from <i>80</i> to <i>100</i></li></ul><p>merged to master.</p>