Subject: Re: [v6ops] draft-korhonen-v6ops-3gpp-eps

From: james woodyatt <[email-masked]>
Date: Tue, 08 Feb 2011 15:20:45 -0800

everyone--

I think I-D.korhonen-v6ops-3gpp-eps could be improved by referencing "Optimistic Duplicate Address Detection (DAD) for IPv6" [RFC 4429].  In particular, I suggest making an explicit mention in section 5.2 by appending the following sentence to the second paragraph:

> Link-local and global unicast addresses composed with this Interface Identifier are eligible for use with the optimistic DAD algorithm [RFC 4429].

An informative reference to RFC 4429 would be appropriate.

--
james woodyatt <[email-masked]>
member of technical staff, core os networking

---

From: james woodyatt <[email-masked]>
Date: Tue, 08 Feb 2011 15:58:54 -0800

On Feb 8, 2011, at 15:26, [email-masked] wrote:

> This I-D is explaining the operation of address assignment, PDP
> context/PDN connection setup procedures as defined in 3GPP. Referencing
> Optimistic DAD in the context of this paragraph without there being
> equivalent text in 3GPP would cause them to be misaligned.

Okay.  Does that mean that the IID signaled in the PDN connection setup is *NOT eligible for use with the RFC 4429 optimistic DAD algorithm?  Why wouldn't it be?  If that's the case, then surely the draft should be amended to explain that!

---

From: james woodyatt <[email-masked]>
Date: Tue, 08 Feb 2011 18:43:11 -0800

Ah.  I see my goof.  The draft says this:

> The details of the 3GPP link-model and address configuration is described in Section 11.2.1.3.2a of [3GPP.29.061].

That document elaborates:

> Since the GGSN guarantees that the Prefix is unique, the MS does not need to perform any Duplicate Address Detection on addresses it creates. That is, the 'DupAddrDetectTransmits' variable in the MS should have a value of zero. If the MS finds more than one Prefix in the Router Advertisement message, it shall only consider the first one and silently discard the others. The GGSN shall not generate any globally unique IPv6 addresses for itself using the Prefix assigned to the MS in the Router Advertisement.

It seems to me like this draft would be improved by spelling that out explicitly here too.

On a related note, I didn't find any specific language in the 3GPP draft explaining what to do when the PIO option in the RA message contains a prefix length shorter than 64 bits.  Seems like an oversight.  One assumes that zero-extending to 64 bits is acceptable, but a normative instruction would be better.

---

From: <[email-masked]>
Date: Tue, 8 Feb 2011 23:26:33 +0000

-Raj

On 2/8/11 5:20 PM, "ext james woodyatt" <[email-masked]> wrote:

>everyone--
>
>I think I-D.korhonen-v6ops-3gpp-eps could be improved by referencing
>"Optimistic Duplicate Address Detection (DAD) for IPv6" [RFC 4429].  In
>particular, I suggest making an explicit mention in section 5.2 by
>appending the following sentence to the second paragraph:
>
>> Link-local and global unicast addresses composed with this Interface
>>Identifier are eligible for use with the optimistic DAD algorithm [RFC
>>4429].
>

---

From: jouni korhonen <[email-masked]>
Date: Wed, 9 Feb 2011 13:04:35 +0200

Hi James,

> It seems to me like this draft would be improved by spelling that out explicitly here too.

Ok. Will check it (the new rev has been lingering on my hdd for quite some time already.. shame on me ;)

> On a related note, I didn't find any specific language in the 3GPP draft explaining what to do when the PIO option in the RA message contains a prefix length shorter than 64 bits.  Seems like an ov…

The 3GPP specs assume normal IPv6 stack behavior in that case i.e. be silent about it. What you have exactly in mind here? SLAAC would work only for /64 and since 3GPP link model only supports a single prefix, having other prefixes shorter than /64 does not make much use. (well I have pushed multiple prefixes over a PDP context and made the mobile configure multiple global addresses but that is different and not really supported)

- Jouni

---

From: james woodyatt <[email-masked]>
Date: Wed, 09 Feb 2011 06:25:47 -0800

On Feb 9, 2011, at 03:04, jouni korhonen wrote:

> since 3GPP link model only supports a single prefix, having other prefixes shorter than /64 does not make much use.

I was trying to point out that the 3GPP spec says what a UE node shall do if the number of advertised prefixes doesn't match the link model, but it doesn't say what to do if the advertised prefix length doesn't match the link model.

It's an exception case, but the devil lurks in details like that.  One hopes the 3GPP people can settle it so that IETF doesn't have to do it.

---

From: Jouni <[email-masked]>
Date: Wed, 9 Feb 2011 18:19:04 +0200

Hi,

> I was trying to point out that the 3GPP spec says what a UE node shall do if the number of advertised prefixes doesn't match the link model, but it doesn't say what to do if the advertised prefix l…

Like I said earlier.. what "any" RFC4861/2 compliant stack does when receiving a RA with a prefix shorter than /64 and any combination of A & L flags. A set, L [un]set  -> the UE ignores the prefix (RFC4862 Section 5.5.3 step d). A unset, L set -> the UE would fiddle its prefix list and consume some resources until the prefix timeouts. A unset, L unset -> The UE does nothing(?) with the prefix. If the shorter than /64 prefix is the only advertised prefix, then the UE just gets no address. Probably the UE would send few more RSes and the rest is up to the UE implementation whether to keep the bearer up or close it.

Of course I cannot guarantee what the legacy does. I believe there are weird stacks out there that try to be too clever (or something) and then manage to misbehave..

> It's an exception case, but the devil lurks in details like that.  One hopes the 3GPP people can settle it so that IETF doesn't have to do it.

It's rather a broken GGSN/PGW implementation if these were to happen.

- Jouni

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 9 Feb 2011 14:10:09 -0500

Hi James,

> On a related note, I didn't find any specific language in the 3GPP draft explaining what to do when the PIO option in the RA message contains a prefix length shorter than 64 bits.  Seems like an ov…

What you are pointing out is right, but it is a generic deficiency of 
RFC4862 that states

"If the sum of the prefix length and interface identifier length
  does not equal 128 bits, the Prefix Information option MUST be
  ignored."

You suggestion of zero extending the prefix to a /64 makes sense, but it 
is probably a configuration error to be advertising a shorter than /64 
prefix in an RA.

Thanks
Suresh