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

Vlad,

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

-----Original Message-----
From: Vlad Yasevich [mailto:vladislav.yasevich@hp.com] 
Sent: Friday, July 06, 2007 3:33 PM
To: Hemant Singh (shemant)
Cc: ipv6@ietf.org
Subject: Re: Sending traffic to default router when RA has no PIO

Hi Hemant

Hemant Singh (shemant) wrote:
> Vlad,
> 
> <vy>
> I believe that you are reading too much into section 3.1.  That 
> section simply does a comparison to IPv4.  It does not mandate 
> anything and doesn't not specify any specific beavhior.  That is saved
for later.
> 
> <hs> Totally agree with you. We want to just add a new line or two to 
> the relevant para in section 3.1 where the new lines say "go to a 
> section further down in the document for concrete details."  Note that

> we simply state that this should be made explicit - but in our 
> introduction, we do not specify exactly how.  For more information on 
> how we wish to be more explicit, see the changes to 2461bis and 
> 2462bis sections.

OK.

> > </vy>
> 
>    These implications in RFC 2461 [ND] need to be made explicit.
>    Failure of host implementations to comply can result in lack of
IPv6
>    connectivity.  For example, a host receives an RA with no prefix
>    advertised and incorrectly decides to perform address resolution
when
>    the host should have sent all traffic to the default router.  The
>    router may not respond to the address resolution and the layer 2
>    driver of the host stops transmitting IPv6 packets.
> 
> <vy>
> Are these meant to describe 2 different scenarios or just one?  
> 
> <hs> Just one scenario. A router may not respond to the NS issued by 
> host to resolve the packet destination. That causes the host's L2 
> driver to just sit there. The net result is no packets get out of the
host.

As I said bellow, both implementation violate the specs.  At this point,
not sure if clarifying the spec by placing additional restrictions is
useful.  Submitting bugs against the implementation is probably better.

<hs> At least in the Introduction section of our I-D, we are just giving
a flavor of the serious nature of IPv6 ND problems. Before we wrote our
I-D, we submitted bugs against the implementation. We have to clarify
2461bis in the areas of data forwarding and address resolution because
some suble behavior can cause major problems in the network. We have
already discussed one serious problem in this mailer. If a host assumed
a /64 prefix length when the host wasn't supposed to assume any prefix
length and added the prefix to the Prefix List, the host would perform
address resolution when instead the host could have considered the
prefix to be off-link and sent data to the default router. As we said
before, the router may not respond to the NS and such a host can loose
IPv6 connectivity. See how a simple assumption caused a serious problem.
That is why we have to make 2461bis more strict in such areas. Our goal
is also to not add any additional requirement over 2461bis. 

> 
> If only one, both implementations violate multiple aspects of the 
> protocol.
> </vy>
> <hs> OK, we will change MUST NOT to SHOULD NOT to allow for clever 
> implementations. One thought we had was that DHCPv6 clients can 
> certainly change address across IPv6 interface initializations - that 
> is what prompted us to this rule having enforced it for SLAAC clients 
> as well. The new bullet text follows:
> 
> "1. On-link determination SHOULD NOT persist across IPv6 interface
"On-link determination state SHOULD NOT persist..."

Makes it a little more clear what you are saying.  Otherwise, looks fine
to me.

> <hs> We noticed this one too and have made a change to this bullet.
> Please see if the new text below for this bullet makes sense to you.
> 
> ---------------
>    "2. The on-link definition in section 2.1 of
>        draft-ietf-ipv6-2461bis-11 [NDbis] describes the only means for
>        on-link determination.  DHCPv6 or any other configuration on
the
>        host MUST NOT be used for on-link determination.  Manual
>        configuration of a host introduces its own set of security
>        considerations and is beyond the scope of this document.  Note
>        that the on-link definition as specified by
>        draft-ietf-ipv6-2461bis-11 [NDbis] does not include manual
>        configuration."
> -----------------

OK.

> 
>    3.  The host MUST NOT add a direct delivery route to the prefix
from
>        an assigned address, independent of the information about the
>        prefix received from the RA or Redirects.
> <vy>
> Can you please explain what exactly you mean here.  I am having 
> difficulty properly understanding this sentence.
> </vy>
> 
> <hs> In this regard, we describe the issue hosts have when hosts 
> incorrectly add a directly connected route to a /64 prefix from an 
> address assigned to an interface, even if the prefix is advertised as 
> "not on-link" or not advertised at all. The host incorrectly assumed a
> /64 prefix length.
> After assuming the prefix length, the host added a directly connected 
> route entry for such a prefix to the host forwarding tables. The 
> incorrectly added route causes the host to try to use direct delivery 
> (without sending traffic to the default router) and, therefore, use 
> NS/NA to resolve addresses from the same prefix.

So, here the implementor completely disregarded either the section about
the L-bit being 0 doesn't mean off-link, or the section at the top of
page
19 of 2462bis to not expect all IIDs to be 64 bit and thus assume a 64
bit prefix.

I guess a final "On-Link Determination" section might help.

<hs> We are working on details on how to incorporate clarifications from
our I-D into 2461bis. We are open right now for a new section.

However, these types of errors are typical of the manual configuration
and there is not much we can do here.

<hs> No, in our testing, we did NOT use manual configuration and still
the host behaved in a non-compliant fashion.  We recognize that manual
configuration can introduce additional problems.  We have already
identified manual configuration in our I-D as potentially introducing
problems -
see the last sentence of bullet 2 of section 2 in our I-D.

> 
> 
>    5.  The host SHOULD issue only a single NS(DAD) for each address.
>        The default value for DupAddrDetectTransmits variable is
>        specified as 1 in section 5.1 of RFC 2462 [ADDRCONF].
> 
> <vy>
> What exactly are you trying to address with this text?  When I read 
> it, my first impulse is to assume that you want to limit the number of

> DAD Soliciations to 1 per address, which is not really correct and is 
> _probably_ not what you mean.  Can you explain a little more.
> </vy>
> 
> <hs> Not quite. This bullet hasn't changed in our I-D from the 
> definition of DupAddrDetectTransmits in 2462bis. Section 5.1 of 
> 2462bis clearly says default value of this variable is 1. Then the 
> section goes on to say the value can be overriden by a linktype 
> specific value. That is why we say in our I-D, the host SHOULD issue 
> only single NS(DAD) because the default is 1. The SHOULD also caters 
> to any other value being used. We found an interesting behavior in an 
> IPv6 cable modem host stack. The modem was sending 4 NS(DAD)'s for 
> Link-local address and 5 NS(DAD)'s for DHCPv6 address.

REALLY???  Unless the modem was explicitly configured to do this, I
don't see how the text you recommend would fix this glaring error...  In
fact, I could claim that this behavior would still be within spec if the
manufacturer or operator determines that they want this behavior.

<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.

> 
> <hs> Agreed. We have to make rules tighter here. Please see the new 
> bullet below:
> 
> ----------------
>     "6. Newer implementations, which are compliant with
>        draft-ietf-ipv6-rfc2461bis-11 [NDbis] MUST adhere to the
>        following rules.  Older implementations, which are compliant
with
>        RFC 2461 [ND] but not draft-ietf-ipv6-rfc2461bis-11 [NDbis] may
>        remain as is.  If the Default Router List is empty and there is
>        no other source of on-link information about any address or
>        prefix:
> 
>        1.  The host MUST NOT assume that all destinations are on-link.
> 
>        2.  The host MUST NOT perform address resolution for non-link-
>            local addresses.
> 
>        3.  The host SHOULD send an ICMPv6 Destination Unreachable
>            message instead.
> 
>        On-link information concerning particular addresses and
prefixes
>        can make those specific addresses and prefixes on-link, but
does
>        not change the default behavior mentioned above for addresses
and
>        prefixes not specified.  draft-ietf-v6ops-onlinkassumption-04
>        [I.D.ietf-v6ops-onlinkassumptions] provides justification for
>        these rules."
> -----------------------

Ok, the text is clearer, but it reads like an over-specification to me.

<hs> We don't think it's over specification. If a host misses first rule
and assumes destinations are on-link, the data delivery break-down can
happen with the host. Bullets 1 and 3 are as is from
draft-ietf-v6ops-onlinkassumption-04.

So many of the issues that you've found have to do with improper
implementation of on-link determination that I am really starting to
thing that a single section on clarifying it would be useful in your
daft.

<hs> Yes, we are putting together such a section.

> 
> 2.1.  RA Sets M and O Bits but does not Include the Prefix Information
>       Option (PIO)
> 
> [... draft text snipped ...]
> 
>    An IPv6 router sends an RA with no prefix advertised and the M and
O
>    bits set and does not send any Redirects.  On receipt of the RA,
the
>    host uses DHCPv6 to acquire an IPv6 address.  After completing IPv6
>    address acquisition, the host MUST obey RFC 2461 [ND], section 3.1.
>    Since the RA is the only authority to a host for on-link
>    determination and this RA does not advertise any prefix, the host
>    cannot determine that a destination is on-link.  Therefore, the
host
>    MUST adhere to the following rules:
> 
>    1.  The host MUST NOT assume any default prefix length.
> 
>    2.  The host MUST send all non-link-local traffic to the default
>        router.
> 
>    3.  The host MUST NOT issue an NS to resolve a destination other
than
>        a link-local address.
> 
> <vy>
> One can argue that a host/DHCP client that inferes a prefix length 
> from a leased address is prone to other failures as well.  In this 
> case, it's the DHCP client that is most likely a problem, unless the 
> host implementation mistakenly alwasy assumes /64 length.  I think 
> this is actually warned against in the Address Architure document.
> 
> <hs> The host implementation has assumed a /64 length in the tests we 
> did.

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.

> 
> 2461bis clearly states that a set 'L' flag is the only determination 
> of on-link.  Anything else you can report to your vendor as "Bug".
> 
> The above actually would be a very good test to add to the TAHI 
> conformance test suite.
> </vy>
> 
> <hs> I contacted TAHI on May 16th, 2007 to add such a test case to the
> IPv6 conformance test suite. On June 19th, 2007, someone replied. I 
> have to work with them to make sure this test is added to their test
suite.

OK.  That would be good.

> 
> 2.2.  RA Advertises a Prefix with the On-link(L) Bit Set
> 
> [... draft text sniped ...]
> 
>    Consider the following scenario with one rogue node and two other
>    hosts on the same link.  The rogue sends a malicious RA with an on-
>    link prefix with a Valid Lifetime of zero.  Host1 correctly
>    implements section 5.5.3 of RFC 2462 [ADDRCONF] and resets its
>    StoredLifetime (or RemainingLifetime in
draft-ietf-ipv6-rfc2462bis-08
>    [ADDRCONFbis]) to two hours and avoids the denial of service
attack.
>    Host1 tries to send traffic to Host2, but cannot trust its own two
>    hour StoredLifetime.  For instance, a legitimate operator may have
>    tried to time out the prefix due to an impending renumbering.
Host1
>    decides to send all of its traffic to the on-link authority, the
>    default router, even though the destination prefix is on-link.
> 
>    IF the host decides to send all traffic (including on-link traffic)
>    to the default router, then the host MUST follow the following
rule:
> 
>    1.  The host MUST NOT issue an NS to resolve a destination other
than
>        a link-local address.
> 
> <vy>
> This is kind of reduntant.  The host can either determine that the 
> destination is on-link (i.e it trusts its prefix list), or it sends it

> to the default router.  The only time it would preform NS would be for

> on-link determination which means that it trust the prefix list.
> I don't see any further need to call out this particular scenario.
> </vy>
> 
> <hs> Before we added these rules, one reviewer complained that we had 
> rules in all the other sections, but not this one.  Therefore, we 
> added the rules to satisfy the reviewer.  As for the scenario, this 
> scenario allows a host to send all traffic to the default router even 
> for a prefix advertised as on-link.  This is very important if we want

> to describe ALL the behavior possible with respect to on-link 
> determination.

OK.

> 
> 2.3.  RA Advertises a Prefix with the On-link(L) Bit Clear

> <hs> You are correct. We changed our I-D for this section - see 
> changed text below:
> 
> "2.3.  RA Advertises a Prefix with the On-link(L) Bit Clear An on-link

> bit of clear indicates nothing regarding on-link determination. In 
> section 6.3.4 of draft-ietf-ipv6-rfc2461bis-11 (Narten, T., Nordmark, 
> E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP Version 6 
> (IPv6)," March 2007.) [NDbis]":
> 
> "...a Prefix Information Option with on-link flag set to zero conveys 
> no information concerning on-link determination and MUST NOT be 
> interpreted to mean that addresses covered by the prefix are 
> off-link.... Prefixes with the on-link flag set to zero would normally

> have the autonomous flag set and be used by [ADDRCONF]."
> "

OK.

> 
> 
> 3.1.  Aggregation Router Deployment Model
> 
>    No NS to resolve any address other that that of the default router
>    will reach the aggregation router from any device on the customer
>    side of the aggregator.  CPEs do not communicate with each other in
>    this deployment model since a CPE does not run any applications
that
>    need to communicate with other CPEs.  Hosts do communicate with
each
>    other, but every host is off-link to any other host on the
>    aggregation router.
> 
> <vy>
> Yes, they are off-link.  So why would they thing their are on-link?
> Each CPE Rtr or Cust Rtr whould have it's own prefix that would be 
> advertized to the CPE hosts.  Therese prefixes would aggregate
> at the Agregator.   Why would NSs from the CPE hosts escape?
> </vy>
> 
> <hs. True the NS's from CPE hosts would not escape. We are just 
> highlighting a deployment design such that the aggregator in the 
> deployment will not have to support ND Proxy.

OK.  But you are going about it by using keyword language (use of SHOULD
in that section).  It just felt odd.  I had to re-read the section a few
times and just couldn't understand the point.  It seemed obvious.

<hs> Our intent for this section is to describe properties of an
aggregation network and not specify any normative changes. We will
change the "SHOULD NOT" to "should not".

> 
> 5.  Changes to draft-ietf-ipv6-rfc2461bis-11
> 
> <vy>
> No, this is the wrong section to include such requirements since the 
> section currenlty doesn't place any specific requirements on the 
> implementation.
> </vy>
> 
> <hs> Agreed. We will put the strict text elsewhere in 2461bis and just

> add a reference in this para to that stricter text.

Yes, this is the same as the first issue.  References are always better.
:)

> 
> 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.

The only thing that _might_ be missing is a reference to such threats
from withing the DAD section, as additional rational for not skipping
DAD, but that's fairly weak.

> 
> My conlcusion:
> 
> After re-reading 2461bis and 2462bis multiple times as result of 
> reviewing this draft, I can see some small value in creating an 
> "On-Link Determination"
> section in draft 2461bis.
> 
> Alternatively, this draft should crate such section and, with 
> references to text in 2461bis, should clarify the on-link
determination behavior.
> It could then be issued as an update.
> 
> <hs> We are preparing text with regards to additional changes to 
> 2461bis to add to Section 5 of our I-D.  We're glad that you agree 
> that on-link determination as described by the current specifications 
> can be confusing.
> 

One thing I've noted is that you have the _same_rules_ in almost every
section.
What I am proposing is that you restructure the text a little.

In each section describe some inconsistencies or behaviors that you've
seen as non-compliant.  Don't add rules to each section.  Instead have
one section where you clarify the behavior using requirement keywords.
Since most issues are centered around on-link determination, that should
be fairly easy.

<hs> We'll think about it and get back to you.

Thanks.

- Hemant & Wes.

-vlad

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------