Subject: [dhcwg] More insight on the prefix length of a DHCPv6 address offered in an IA_ADDR option

From: "Leino, Tammy" <[email-masked]>
Date: Thu, 30 Aug 2007 14:31:53 -0500

Hello All,

I have been testing my DHCPv6 client implementation using the phase-2 TAHI test suite, and I am seeing interesting behaviour that gives insight into how the TAHI group is interpreting on-link routing and prefix length in regards to RFC 3315.  When the TAHI test assigns the NUT a global IPv6 address, it expects the NUT to know that the prefix associated with that address is on link.  Here is what happens:

1 -
TAHI sends RA with link-layer addr 00:00:00:00:a6:a6 - this is important, as the rest of the packets are sent with a different link-layer address.

NUT adds Default Router with this link-layer address.

2 -
NUT invokes DHCPv6 client 

TAHI assigns NUT IPv6 address 3ffe:501:ffff:100:2a0:7dff:fe08:1

3-
TAHI pings NUT:

source IPv6 address : 3ffe:501:ffff:100:200:ff:fe00:a1a1
source link-layer address : 00:00:00:00:a1:a1

destination address : 3ffe:501:ffff:100:2a0:7dff:fe08:1

Now, this is where things get interesting.  If I did not add a route for the prefix associated with the assigned address indicating that this prefix is on-link, the NUT will assume the destination to the echo reply is off-link and send the packet through the router.  When this happens, TAHI does not recognize receipt of this echo reply packet since it is sent to link-layer address 00:00:00:00:a6:a6 instead of 00:00:00:00:a1:a1.  TAHI requires that the packet be sent to the link-layer address that sent the request; therefore, the NUT must know that the source is on-link and that the prefix associated with the address assigned by the DHCPv6 server is on-link.

I was previously using a prefix length of 128 for an address assigned through DHCPv6, per suggestions received on a previous thread, but now I am using 64.

I'm not trying to open a can of worms again here.  I just wanted to share my observations with the group.

Best Regards,
Tammy Leino

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

---

From: Ralph Droms <[email-masked]>
Date: Thu, 30 Aug 2007 15:45:38 -0400

Tammy - are there any prefix information options in the RA sent by  
the TAHI test suite in step 1?

- Ralph

On Aug 30, 2007, at Aug 30, 2007,3:31 PM, Leino, Tammy wrote:

> Hello All,
>
> I have been testing my DHCPv6 client implementation using the  
> phase-2 TAHI test suite, and I am seeing interesting behaviour that  
> gives insight into how the TAHI group is interpreting on-link  
> routing and prefix length in regards to RFC 3315.  When the TAHI  
> test assigns the NUT a global IPv6 address, it expects the NUT to  
> know that the prefix associated with that address is on link.  Here  
> is what happens:
>
> 1 -
> TAHI sends RA with link-layer addr 00:00:00:00:a6:a6 - this is  
> important, as the rest of the packets are sent with a different  
> link-layer address.
>
> Now, this is where things get interesting.  If I did not add a  
> route for the prefix associated with the assigned address  
> indicating that this prefix is on-link, the NUT will assume the  
> destination to the echo reply is off-link and send the packet  
> through the router.  When this happens, TAHI does not recognize  
> receipt of this echo reply packet since it is sent to link-layer  
> address 00:00:00:00:a6:a6 instead of 00:00:00:00:a1:a1.  TAHI  
> requires that the packet be sent to the link-layer address that  
> sent the request; therefore, the NUT must know that the source is  
> on-link and that the prefix associated with the address assigned by  
> the DHCPv6 server is on-link.
>
> I was previously using a prefix length of 128 for an address  
> assigned through DHCPv6, per suggestions received on a previous  
> thread, but now I am using 64.
>

---

From: "Leino, Tammy" <[email-masked]>
Date: Thu, 30 Aug 2007 14:52:47 -0500

Hi Ralph,

Yes, there is one prefix option in the RA that corresponds to the
address that will be assigned later by the DHCP server, but part of the
test is to ignore the prefix info option of the RA since the auto flag
is not set.  Should I be "remembering" the prefix length of this prefix
option even though I am not permitted to assign this prefix to the node?

Best Regards,
Tammy

-----Original Message-----
From: Ralph Droms [mailto:[email-masked]]
Sent: Thursday, August 30, 2007 3:46 PM
To: Leino, Tammy
Cc: [email-masked]
Subject: Re: [dhcwg] More insight on the prefix length of a DHCPv6
address offered in an IA_ADDR option

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Thu, 30 Aug 2007 16:11:34 -0400

Tammy - my understanding of RFC 2461 is that the stack should install  
that advertised prefix in the Prefix List as an on-link prefix, even  
if the A bit is not set.  With the prefix in the Prefix List, the  
host should consider the prefix and the source of the ping to be on- 
link, and deliver the response to:

IPv6 address : 3ffe:501:ffff:100:200:ff:fe00:a1a1
link-layer address : 00:00:00:00:a1:a1

- Ralph

---

From: "Leino, Tammy" <[email-masked]>
Date: Thu, 30 Aug 2007 15:17:20 -0500

Thanks Ralph.

I should be adding a route for this prefix when I get the RA, just not
creating an address from the prefix.  This sheds some light on comments
made by other members of the list a couple weeks ago that made no sense
then!

Many thanks for the clarification!

Best Regards,
Tammy

-----Original Message-----
From: Ralph Droms [mailto:[email-masked]]
Sent: Thursday, August 30, 2007 4:12 PM
To: Leino, Tammy
Cc: [email-masked]
Subject: Re: [dhcwg] More insight on the prefix length of a DHCPv6

- Ralph

---

From: Josh Littlefield <[email-masked]>
Date: Thu, 30 Aug 2007 16:30:44 -0400

Tammy, I think Ralph was making the assumption that the 'L' bit was set
in the advertised prefixes in the RA.

RFC 2461, sec. 6 (Router and Prefix Discovery) describes the two
independent uses of prefix options:

   Prefix Discovery is the process through which hosts learn the ranges
   of IP addresses that reside on-link and can be reached directly
   without going through a router.  Routers send Router Advertisements
   that indicate whether the sender is willing to be a default router.
   Router Advertisements also contain Prefix Information options that
   list the set of prefixes that identify on-link IP addresses.

   Stateless Address Autoconfiguration must also obtain subnet prefixes
   as part of configuring addresses.  Although the prefixes used for
   address autoconfiguration are logically distinct from those used for
   on-link determination, autoconfiguration information is piggybacked
   on Router Discovery messages to reduce network traffic.  Indeed, the
   same prefixes can be advertised for on-link determination and address
   autoconfiguration by specifying the appropriate flags in the Prefix
   Information options.  See [ADDRCONF] for details on how
   autoconfiguration information is processed.

In sec. 6.3.4 it goes on to say:

   For each Prefix Information option with the on-link flag set, a host
   does the following:

      - If the prefix is the link-local prefix, silently ignore the
        Prefix Information option.

      - If the prefix is not already present in the Prefix List, and the
        Prefix Information option's Valid Lifetime field is non-zero,
        create a new entry for the prefix and initialize its
        invalidation timer to the Valid Lifetime value in the Prefix
        Information option.

      - If the prefix is already present in the host's Prefix List as
        the result of a previously-received advertisement, reset its
        invalidation timer to the Valid Lifetime value in the Prefix
        Information option.  If the new Lifetime value is zero, time-out
        the prefix immediately (see Section 6.3.5).

      - If the Prefix Information option's Valid Lifetime field is zero,
        and the prefix is not present in the host's Prefix List,
        silently ignore the option.

-- 
=====================================================================
Josh Littlefield                                  Cisco Systems, Inc.
[email-masked]                             1414 Massachusetts Avenue
tel: 978-936-1379  fax: 978-936-2226       Boxborough, MA  01719-2205

---

From: "Leino, Tammy" <[email-masked]>
Date: Thu, 30 Aug 2007 15:36:00 -0500

Thank you Josh.  The L bit was set in the RA.  The A bit was not set.
 
Best Regards,
Tammy

-----Original Message-----
From: Josh Littlefield [mailto:[email-masked]]
Sent: Thursday, August 30, 2007 4:31 PM
To: Leino, Tammy
Cc: Ralph Droms; [email-masked]
Subject: Re: [dhcwg] More insight on the prefix length of a DHCPv6 address offered in an IA_ADDR option

Tammy, I think Ralph was making the assumption that the 'L' bit was set in the advertised prefixes in the RA.

RFC 2461, sec. 6 (Router and Prefix Discovery) describes the two independent uses of prefix options:

   does the following:

        Information option.

Leino, Tammy wrote: 

Thanks Ralph.

then!

Best Regards,

Tammy

-----Original Message-----

From: Ralph Droms [ mailto:[email-masked]]

To: Leino, Tammy

Cc:  [email-masked]

- Ralph

  

Hi Ralph,

address that will be assigned later by the DHCP server, but part of  

the

is not set.  Should I be "remembering" the prefix length of this  

prefix

option even though I am not permitted to assign this prefix to the  

node?

Best Regards,

Tammy

-----Original Message-----

From: Ralph Droms [ mailto:[email-masked]]

To: Leino, Tammy

Cc:  [email-masked]

- Ralph

    

Hello All,

is what happens:

1 -

link-layer address.

2 -

3-

TAHI pings NUT:

I'm not trying to open a can of worms again here.  I just wanted to

share my observations with the group.

Best Regards,

Tammy Leino

dhcwg mailing list

[email-masked]

dhcwg mailing list

[email-masked]

--