Subject: Re: [dna] #9: Detailed description of ND packets

From: "dna issue tracker" <[email-masked]>
Date: Mon, 03 Nov 2008 02:09:31 -0000

#9: Detailed description of ND packets
------------------------------------------+---------------------------------
 Reporter:  [email-masked]  |        Owner:  Suresh Krishnan
     Type:  defect                        |       Status:  closed         
 Priority:  major                         |    Milestone:                 
Component:  simple                        |      Version:                 
 Severity:  Active WG Document            |   Resolution:  fixed          
 Keywords:                                |  
------------------------------------------+---------------------------------
Changes (by [email-masked]):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 4.5.  Contents of the Neighbor Discovery messages

 4.5.1.  Neighbor Solicitation messages

    This section describes the contents of the neighbor solicitation
    probe messages sent during the probing procedure.

    Source Address:           A link-local address assigned to the
                              probing host.

    Destination Address:      The link-local address of the router being
                              probed as leaFrom [email-masked]  Sun Nov  2 18:09:38 2008
From: "dna issue tracker" <[email-masked]>
Auto-Submitted: auto-generated
To: [email-masked]
Date: Mon, 03 Nov 2008 02:09:31 -0000
Cc: [email-masked]
Subject: Re: [dna] #9: Detailed description of ND packets
Reply-To: [email-masked]
Sender: [email-masked]

#9: Detailed description of ND packets
------------------------------------------+---------------------------------
 Reporter:  [email-masked]  |        Owner:  Suresh Krishnan
     Type:  defect                        |       Status:  closed         
 Priority:  major                         |    Milestone:                 
Component:  simple                        |      Version:                 
 Severity:  Active WG Document            |   Resolution:  fixed          
 Keywords:                                |  
------------------------------------------+---------------------------------
Changes (by [email-masked]):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 4.5.  Contents of the Neighbor Discovery messages

 4.5.1.  Neighbor Solicitation messages

    This section describes the contents of the neighbor solicitation
    probe messages sent during the probing procedure.

    Source Address:           A link-local address assigned to the
                              probing host.

    Destination Address:      The link-local address of the router being
                              probed as learnt frrnt from the SDAT.

    Hop Limit:                255

    ND Options:

    Target Address:           The link-local address of the router being
                              probed as learnt from the SDAT.

    The probing node SHOULD NOT include a Source link-layer address
    option if it has not performed duplicate address detection [RFC4862],
    for the source address of the NS, on the newly attached link.

 4.5.2.  Router Solicitation messages

    This section describes the contents of the router solicitation probe
    message sent during the probing procedure.

    Source Address:           A link-local address assigned to the
                              probing host.

    Destination Address:      The all-routers multicast address.

    Hop Limit:                255

    The probing node SHOULD NOT include a Source link-layer address
    option if it has not performed duplicate address detection [RFC4862],
    for the source address of the NS, on the newly attached link.

-- 
Ticket URL: <http://svn.tools.ietf.org/wg/dna/trac/ticket/9#comment:1>
dna <http://tools.ietf.org/dna/>

_______________________________________________
dna mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dna

om the SDAT.

    Hop Limit:                255

    ND Options:

    Target Address:           The link-local address of the router being
                              probed as learnt from the SDAT.

    The probing node SHOULD NOT include a Source link-layer address
    option if it has not performed duplicate address detection [RFC4862],
    for the source address of the NS, on the newly attached link.

 4.5.2.  Router Solicitation messages

    This section describes the contents of the router solicitation probe
    message sent during the probing procedure.

    Source Address:           A link-local address assigned to the
                              probing host.

    Destination Address:      The all-routers multicast address.

    Hop Limit:                255

    The probing node SHOULD NOT include a Source link-layer address
    option if it has not performed duplicate address detection [RFC4862],
    for the source address of the NS, on the newly attached link.

-- 
Ticket URL: <http://svn.tools.ietf.org/wg/dna/trac/ticket/9#comment:1>
dna <http://tools.ietf.org/dna/>

_______________________________________________
dna mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dna

---

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 3 Nov 2008 15:48:05 -0800

There is an issue in Section 4.5.1.  This section should also describe the
link layer addresses in the NS packet, to make clear that the NS is
sent to the previously cached link layer address of the router (NOT to
a multicast address).  

"   The probing node SHOULD NOT include a Source link-layer address
   option if it has not performed duplicate address detection [RFC4862],
   for the source address of the NS, on the newly attached link."

In DNAv4 (RFC 4436), the goal was not only to detect network attachment, but
also to establish bi-directional reachability.  By not including the Source
link-layer address, Simple DNA does not achieve this goal. 

Assuming that the NS is sent to a unicast MAC address of the target router,
it will not
be received unless the host is attached to the router from which it had
previously 
obtained an address.  Assuming that the host had previously done duplicate
address
detection and that the address is still presumed operable (e.g. this wasn't
done so
long ago as to be uselesFrom [email-masked]  Mon Nov  3 15:48:18 2008
From: "Bernard Aboba" <[email-masked]>
To: <[email-masked]>,
	<[email-masked]>
Date: Mon, 3 Nov 2008 15:48:05 -0800
Subject: Re: [dna] #9: Detailed description of ND packets
Sender: [email-masked]

There is an issue in Section 4.5.1.  This section should also describe the
link layer addresses in the NS packet, to make clear that the NS is
sent to the previously cached link layer address of the router (NOT to
a multicast address).  

"   The probing node SHOULD NOT include a Source link-layer address
   option if it has not performed duplicate address detection [RFC4862],
   for the source address of the NS, on the newly attached link."

In DNAv4 (RFC 4436), the goal was not only to detect network attachment, but
also to establish bi-directional reachability.  By not including the Source
link-layer address, Simple DNA does not achieve this goal. 

Assuming that the NS is sent to a unicast MAC address of the target router,
it will not
be received unless the host is attached to the router from which it had
previously 
obtained an address.  Assuming that the host had previously done duplicate
address
detection and that the address is still presumed operable (e.g. this wasn't
done so
long ago as to be useless), ths), then there is no risk of neighbor cache
pollution.  
Either the NS packet vanishes into space, or it is received by the router to
which
it was addressed, with little risk of neighbor cache pollution. 

Given this, it would seem to me that in any situation in which an NS probe
would be
recommended, the Source link-layer address should be included.  Where
duplicate
address detection was never performed, or where it is no longer valid, there
is
no address to confirm, so that doing simple DNAv6 doesn't make sense. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of dna
issue tracker
Sent: Sunday, November 02, 2008 6:10 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [dna] #9: Detailed description of ND packets

  * status:  new => closed
  * resolution:  => fixed

Comment:

    Hop Limit:                255

    ND Options:

    Hop Limit:                255

en there is no risk of neighbor cache
pollution.  
Either the NS packet vanishes into space, or it is received by the router to
which
it was addressed, with little risk of neighbor cache pollution. 

Given this, it would seem to me that in any situation in which an NS probe
would be
recommended, the Source link-layer address should be included.  Where
duplicate
address detection was never performed, or where it is no longer valid, there
is
no address to confirm, so that doing simple DNAv6 doesn't make sense. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of dna
issue tracker
Sent: Sunday, November 02, 2008 6:10 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [dna] #9: Detailed description of ND packets

  * status:  new => closed
  * resolution:  => fixed

Comment:

    Hop Limit:                255

    ND Options:

    Hop Limit:                255

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 04 Nov 2008 18:11:43 -0500

Hi Bernard,

> sent to the previously cached link layer address of the router (NOT to

Will do.

> link-layer address, Simple DNA does not achieve this goal. 

I think this comes back to the issue on when DAD is required. I do
understand your point, but I still see an issue with putting the SLLAO
in the packet when we are not reasonably sure that the address is not
duplicated. From your mail, I see that you consider the chance of
the address being taken by some other node as very low. I do not know
how to quantify this in text. If I can quantify when DAD is not
required, I thinkFrom [email-masked]  Tue Nov  4 15:13:38 2008
Date: Tue, 04 Nov 2008 18:11:43 -0500
From: Suresh Krishnan <[email-masked]>
To: Bernard Aboba <[email-masked]>
Cc: [email-masked]
Subject: Re: [dna] #9: Detailed description of ND packets
Sender: [email-masked]

Hi Bernard,

> sent to the previously cached link layer address of the router (NOT to

Will do.

> link-layer address, Simple DNA does not achieve this goal. 

I think this comes back to the issue on when DAD is required. I do
understand your point, but I still see an issue with putting the SLLAO
in the packet when we are not reasonably sure that the address is not
duplicated. From your mail, I see that you consider the chance of
the address being taken by some other node as very low. I do not know
how to quantify this in text. If I can quantify when DAD is not
required, I think it wi it will be very straight forward to address your 
concern. Do you have any suggestions?

Thanks
Suresh

ll be very straight forward to address your 
concern. Do you have any suggestions?

Thanks
Suresh

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 4 Nov 2008 23:33:30 -0800

Comments below. 

> Date: Tue, 4 Nov 2008 18:11:43 -0500
> From: [email-masked]
> To: [email-masked]
> CC: [email-masked]
> I think this comes back to the issue on when DAD is required. 
> I do understand your point, but I still see an issue with putting the SLLAO
> in the packet when we are not reasonably sure thaFrom [email-masked]  Tue Nov  4 23:33:36 2008
From: Bernard Aboba <[email-masked]>
To: Suresh Krishnan <[email-masked]>
Date: Tue, 4 Nov 2008 23:33:30 -0800
Importance: Normal
Cc: [email-masked]
Subject: Re: [dna] #9: Detailed description of ND packets
Sender: [email-masked]

Comments below. 

> Date: Tue, 4 Nov 2008 18:11:43 -0500
> From: [email-masked]
> To: [email-masked]
> CC: [email-masked]
> I think this comes back to the issue on when DAD is required. 
> I do understand your point, but I still see an issue with putting the SLLAO
> in the packet when we are not reasonably sut the address is not
> required, I think it will be very straight forward to address your 

A potential suggestion:

The probing node SHOULD include a Source link-layer address option
if either:

a. the probing node has performed duplicate address detection [RFC4862]
after attachment; 

a. the probing node has previously performed duplicate address detection 
[RFC4862] for the source address included within the NS,  and the
conditions described in Section X are satisfied, so that the results of
the prior DAD are still considered valid.