Subject: [v6ops] new draft: draft-ietf-v6ops-3gpp-eps-00.txt

From: Fred Baker <[email-masked]>
Date: Thu, 7 Apr 2011 07:11:25 -0700 (PDT)

A new draft has been posted, at http://tools.ietf.org/draft-ietf-v6ops-3gpp-eps-00.txt. Please take a look at it and comment.

---

From: jouni korhonen <[email-masked]>
Date: Wed, 27 Apr 2011 23:30:56 +0300

Hi,

As mentioned in Prague meeting presentation, the draft could have a reference to RFC3316 and some text on related topics. Here's the proposed text:

5.4.  IPv6 Neighbor Discovery Considerations

   3GPP link between the UE and the next hop router (e.g.  GGSN)
   resemble a point to point (p2p) link, which has no link layer
   addresses [RFC3316] and this has not changed from 2G/3G GPRS to EPS.
   The UE IP stack has to take this into consideration.  When the 3GPP
   PDP Context appears as a PPP interface/link to the UE, the IP stack
   is usually prepared to handle Neighbor Discovery protocol and the
   related Neighbor Cache state machine transitions in an appropriate
   way, even thought Neighbor Discovery protocol messages contain no
   link layer address information.  However, some operating systems
   discard Router Advertisements on their PPP interface/link as a
   default setting.  This causes the SLAAC to fail when the 3GPP PDP
   Context gets established, thus stalling all IPv6 traffic.

   Currently several operating systems and their network drivers can
   make the 3GPP PDP Context to appear as an IEEE802 interface/link to
   the IP stack.  This has few known issues, especially when the IP
   stack is made to believe the underlying link has link-layer
   addresses.  First, the Neighbor Advertisement sent by a GGSN as a
   response to an address resolution triggered Neighbor Solicitation may
   not contain a Target Link-Layer address option (as suggested in
   [RFC4861] Section 4.4).  Then it is possible that the address
   resolution never completes when the UE tries to resolve the link-
   layer address of the GGSN, thus stalling all IPv6 traffic.

   Second, the GGSN may simply discard all address resolution triggered
   Neighbor Solicitation messages (as hinted in [RFC3316] Section 2.4.1
   that address resolution and next-hop determination are not needed).
   As a result the address resolution never completes when the UE tries
   to resolve the link-layer address of the GGSN, thus stalling all IPv6
   traffic.

- Jouni

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 28 Apr 2011 08:35:00 -0700 (PDT)

> Hi,
> 
> As mentioned in Prague meeting presentation, the draft could have a  reference 

>to RFC3316 and some text on related topics. Here's the proposed  text:
> 

I think this has been fixed in EPS.
PDN GW sends UE Interface Identifier in 
Create Default Bearer Response message and IId eventually gets delivered to the 
UE.
The solution applies to 3G MS's connected to the EPC via R8 SGSNs.

Regards,

Behcet

---

From: jouni korhonen <[email-masked]>
Date: Thu, 28 Apr 2011 23:47:46 +0300

You are mixing topics now. The text below talks about link-layer addresses, not interface identifiers. See Section 5.2 for a discussion about interface identifiers.

- Jouni

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 28 Apr 2011 15:24:21 -0700 (PDT)

> You are mixing topics now. The text below talks about link-layer addresses,  
>not interface 
>

> identifiers. 

Well, you can obtain LLA from an Iid, right?

> See Section 5.2 for a discussion about interface  identifiers.

But the text you proposed in your mail is more talking about the UE not able to 
get the LLA of GGSN thus failing the neighbor discovery.
So in theory, UE can provide an LLA during an ND exchange.

I think it (this whole thing) is splitting hairs.

Regards,

Behcet

---

From: jouni korhonen <[email-masked]>
Date: Fri, 29 Apr 2011 09:00:12 +0300

> Well, you can obtain LLA from an Iid, right?

Yes.. assuming the IID in the first place was derived from interface's real link-layer address, which is not the case here.. because the link in question here has no link-layer addresses.

> get the LLA of GGSN thus failing the neighbor discovery.

I find it annoying from the end user point of view, when it happens.

> So in theory, UE can provide an LLA during an ND exchange.

You are again missing the context here. I was not writing "in theory"

  "link layer address information.  However, some operating systems
   discard Router Advertisements on their PPP interface/link as a.."

  "Currently several operating systems and their network drivers can
   make the 3GPP PDP Context to appear as an IEEE802 interface/link to
   the IP stack.  This has few known issues, especially when the IP.."

> I think it (this whole thing) is splitting hairs.

This is a corner case but rather annoying one.

- Jouni