RE: Sending traffic to default router when RA has no PIO

["Hemant Singh (shemant)" <[e-mail]>]

Vlad & Tatuya,

Please see in line below with "<hs>".

Tatuya, please note another proposed change by Vlad to 2462bis and also
Vlad agrees that a change regarding skipping DAD should be made to
2462bis as per this statement from Vlad: "I would agree to adding the
rationale for why skipping DAD is not recommended."

-----Original Message-----
From: Vlad Yasevich [mailto:[e-mail]] 
Sent: Monday, July 09, 2007 10:45 AM
To: Hemant Singh (shemant)
Cc: [e-mail]
Subject: Re: Sending traffic to default router when RA has no PIO

Hi Hemnat

Hemant Singh (shemant) wrote:
> <hs> We also told the modem vendor their behavior is compliant with ND

> RFC but since bandwidth is limited in a broadband deployment in the 
> upsteam direction (modem to the aggregation router), having each modem

> issue 9 DAD's before the modem got online was a waste of valuable 
> bandwidth resource. As 2462bis says, it's up to a link-type document 
> to modify this value. Aggregation router standards will have to take 
> care of specifying such a value for broadband deployments IF they 
> choose to use a different value than the default value of 1.
> 
> So the new text you are introducing would be completely nullified.
> 
> <hs> True. Our aim with this bullet is to only raise an awareness that

> default value is 1. Many new IPv6 host developers just read 2461bis 
> and miss the default value of this variable that is not specified in 
> 2461bis, but is specified in 2462bis.

IMO this is already fairly well spelled out in 2461bis.  There was talk
earlier on the list of adding something along the list of:
    This document RECOMMENDS that implementations use default values
specified
    here.

<hs> Since we are working on how to fold in text from our I-D as changes
to 2461bis, this bullet 5 from section 2 of our I-D will also fall into
that work of where to specify this recommendation in 2461bis.

I don't remember what happened to that, but that should do what you
want.
> 
> <hs> Yes, we are putting together such a section.
> 

OK. I'll wait for the new text.

> 
> Yes, and 2462bis weasel words around this issue at the top of page 19.
> Maybe a "should" there needs to be changed to a "SHOULD"?
> 
> <hs> Which words are you talking about? Quick look at 2462bis and even

> 2461bis on page 19 did not show us any relevant words.

      Note that a future revision of the address architecture [RFC3513]
      and a future link-type specific document, which will still be
      consistent with each other, could potentially allow for an
      interface identifier of length other than the value defined in the
      current documents.  Thus, an implementation should not assume a
      particular constant.  Rather, it should expect any lengths of
      interface identifiers.

I suggest the 'should' in the last sentence be replaced by SHOULD.

<hs> Ah, this is text on page 17 of 2462bis -08. Good catch. We agree
that the "should" be replaced with SHOULD. So does Tatuya want to make
such a change to 2462bis before sending it off?

>> 6.  Changes to draft-ietf-ipv6-rfc2462bis-08
>>
>> [... old text snipped ...]
>>
>>    to read as follows:
>>
>>       Each individual unicast address SHOULD be tested for
uniqueness.
>>       Note that some deployed implementations perform Duplicate
> Address
>>       Detection (DAD) only for the link-local address and skip the
> test
>>       for the global address using the same interface identifier.
>>       Whereas this document does not invalidate such implementations,
>>       this kind of 'optimization' is NOT RECOMMENDED, and new
>>       implementations MUST NOT do that optimization.  This
> optimization
>>       came from the assumption that all of an interface's addresses
> are
>>       generated from the same interface identifier (see RFC 2462
>>       [ADDRCONF]).  However, even with this assumption, skipping DAD
> for
>>       non-link-local addresses with manual configuration creates an
>>       additional problem.  This optimization allows an interface to
>>       claim a duplicate address in a way that would not be detected.
>>       For a more detailed description of this problem, see the Host
>>       Models section of
>>       draft-wbeebee-nd-implementation-pitfalls-01.  Further, new
>>       types of addresses have been introduced where the interface
>>       identifiers are not necessarily the same for all unicast
> addresses
>>       on a single interface [RFC3041] [RFC3972].  Requiring an
> interface
>>       to perform DAD for all unicast addresses will make the
algorithm
>>       more robust.
>>
>> <vy>
>> Two issues:
>>  1. This text is not any stronger then the existing text in 2461bis
> and
>>     doesn't add anything significant.
>>
>> <hs> Yes it is. We have been told by a number of people that whether 
>> to skip DAD or not was discussed at length in the IETF IPv6 WG and
> mailer.
>> If so much discussion happened and RFC 2462 changed in 2462bis I-D to

>> remove the skipping DAD requirement for newer hosts, we'd like to see

>> the reasons for the change. The only reason we found in 2462bis for 
>> the change was:
>>
>>       "new types of addresses have been introduced where the
>>       interface identifiers are not necessarily the same for all
> unicast
>>       addresses on a single interface [RFC3041] [RFC3972]."
>>
>> Well, we provided an example scenario in our I-D (section 2, bullet 
>> 4)
> 
>> that highlights that fact the skipping DAD combined with manual 
>> configuration can result in duplicate addresses on the same link 
>> which
> 
>> are not detected.
> 
> The example you provide has been documented in the Neighbor Discover 
> Threats spec (rfc 3756).  So that's documented fairly well.  The 
> Security Consideration section also references it and points out 
> issues with DAD.
> 
> <hs> No, we disagree that the problem we have highlighted in bullet 4 
> of our I-D is mentioned anywhere in RFC 3756 - you will have to point 
> it out to us.  Our problem is saying mixing "skipping DAD" and manual 
> configuration is a bad idea and also shows that even if Link-local 
> address and Global Unique Address (GUA) of the host are created from 
> the same identifier (Host2 in our example), one will have duplicate 
> addresses on the link that would not be detectable. Further, this 
> problem is detectable if DAD is not skipped for the GUA by Host2. The 
> duplicate will be detected because even Host1 is a compliant host in 
> our model, not a rogue host. Please see an earlier email discussion 
> between ourselves and Tataya on this one.

You are right.  I just re-read 3756 and this item is not there.  I would
agree to adding the rationale for why skipping DAD is not recommended.
Any additional text can be safely removed.

<hs> OK, so we have reached consensus between us for changing the text
of 2462bis. We like our original paragraph because it clearly mentions
manual configuration, which is not mentioned in your suggested
paragraph.

Thanks.

- Hemant & Wes

Something like:
   -  Each individual unicast address SHOULD be tested for uniqueness.
      Note that there are implementations deployed that only perform
      Duplicate Address Detection for the link-local address and skip
      the test for the global address using the same interface
      identifier as that of the link-local address.  Whereas this
      document does not invalidate such implementations, this kind of
      "optimization" is NOT RECOMMENDED, and new implementations MUST
      NOT do that optimization.  This optimization came from the
      assumption that all of an interface's addresses are generated from
      the same identifier.  However, the assumption does not actually
      stand; new types of addresses have been introduced where the
      interface identifiers are not necessarily the same for all unicast
      addresses on a single interface [RFC3041] [RFC3972].
Additionally,
      hosts that implement the "optimization" may end up configuring
      duplicate addresses and causing network disruptions.  Requiring to
      perform Duplicate Address Detection for all unicast addresses will
      make the algorithm robust for the current and future such special
      interface identifiers.

-vlad

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------