Subject: [dhcwg] DHCPv6 Stateful Prefix Length

From: RamaSubramanian KrishnaMurthi <[email-masked]>
Date: Thu, 27 Sep 2007 22:42:07 -0700 (PDT)

Hi all,
   I don't whether this question has been asked early or not.

    Can the DHCPv6 Stateful server send Prefix length of the IPv6 Address that is being sent to client ? Is there any RFC that talks about ?
 
  If the DHCPv6 Stateful server doesn't send the prefix length what the prefix value that dhcpv6 stateful client should assume ?

Yours ever
-RamaSubbu SK

      ____________________________________________________________________________________
Shape Yahoo! in your own image.  Join our Network Research Panel today!   http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 

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

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Fri, 28 Sep 2007 08:56:32 -0400

A host should use information from the Router Advertisements (in
particular, from the Prefix Information Options in the RA).

If there is no information in the RA about a prefix that contains the
address, then /128 should be assumed.

- Bernie

-----Original Message-----
From: RamaSubramanian KrishnaMurthi [mailto:[email-masked]] 
Sent: Friday, September 28, 2007 1:42 AM
To: [email-masked]
Subject: [dhcwg] DHCPv6 Stateful Prefix Length

Hi all,

    Can the DHCPv6 Stateful server send Prefix length of the IPv6
Address that is being sent to client ? Is there any RFC that talks about
?
 
  If the DHCPv6 Stateful server doesn't send the prefix length what the
prefix value that dhcpv6 stateful client should assume ?

Yours ever
-RamaSubbu SK

________________________________________________________________________
____________
Shape Yahoo! in your own image.  Join our Network Research Panel today!
http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7

---

From: Alain Durand <[email-masked]>
Date: Fri, 28 Sep 2007 09:57:10 -0400

As we have seen in the DHCPv6 bake-off, this is not implemented by every
body and creates inter issues. It would be much cleaner to have such an
option.

    - Alain.

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Fri, 28 Sep 2007 10:26:50 -0400

I'm not convinced of that yet. I think Tim Chown is writing an I-D about
this topic (perhaps he already has)?

>From the Chicago minutes
(http://www3.ietf.org/proceedings/07jul/minutes/dhc.txt):

---
Extensions to DHCPv6 for prefix and default router information

Tim Chown led a discussion of handling rogue RAs in an IPv6
deployment.  The motivation for this presentation is that
administrators of operational networks, mostly universities are
comfortable with DHCP, but are finding problems with 'rogue Router
Advertisments'.  One possible alternative is to avoid RAs and use DHCP
for prefix and default router information. 

Bogus RAs can originate from several sources:

1) configuration error - sometimes with long lifetime
2) User-induced accidents: host acting as 6to4 router from home
3) malice

Arkko said that it's not clear DHCP is the right way to deal with
these problems.  Dave Thaler pointed out that SeND is the official
solution to this problem, so creating another solution does not
improve the situation.  Thaler also pointed out that, with the
revision to the "on-link assumption" in RFC 2461bis, there may be a
need for passing prefix information in DHCP.  Alain Durand expressed
interest in using DHCP for prefix and default router information.  Tim
Chown promised to publish a draft documenting the problem. 
---

If we were to consider such an option, there needs to be a lot of
thought as to what happens if you have BOTH an RA and DHCPv6 option and
they conflict in what they are telling the client. This also gets
complicated because you could have "normal" RAs, SeND RAs,
unauthenticated DHCPv6, and authenticated DHCPv6. And, you also need to
add manual configuration to that too (though that might be easy enough
to let it always "win"). I'm not even sure what happens today if there
is conflicting information from RAs (SeND or not).

- Bernie

-----Original Message-----
From: Alain Durand [mailto:[email-masked]] 
Sent: Friday, September 28, 2007 9:57 AM
To: Bernie Volz (volz); RamaSubramanian KrishnaMurthi; [email-masked]
Subject: Re: [dhcwg] DHCPv6 Stateful Prefix Length

    - Alain.

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Fri, 28 Sep 2007 10:26:50 -0400

---

Tim Chown led a discussion of handling rogue RAs in an IPv6
deployment.  The motivation for this presentation is that
administrators of operational networks, mostly universities are
comfortable with DHCP, but are finding problems with 'rogue Router
Adverom rtp-dkim-1.cisco.com ([64.102.121.158])
	by rtp-iport-2.cisco.com with ESMTP; 28 Sep 2007 10:27:03 -0400
Content-class: urn:content-classes:message
Date: Fri, 28 Sep 2007 10:27:02 -0400
From: "Bernie Volz \(volz\)" <[email-masked]>
To: "Kasi Sambandam" <[email-masked]>, <[email-masked]>
Cc: 
Subject: [dhcwg] RE: A doubt in RFC 3315

This is a multi-part message in MIME format.

--=======66162089=
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C801DB.A2EA33E0"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C801DB.A2EA33E0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Kasi:
 
It is best to send questions like this to the dhc wg.
 
My own view is that all messages which are NOT retransmissions should
have a new transaction-id. Therefore the Solicit has one transaction id
(and of course the Advertise will have the same) and the Request (and
thus Reply) should use a different transaction id.
 
- Bernie

________________________________

From: Kasi Sambandam [mailto:[email-masked]] 
Sent: Friday, September 28, 2007 6:04 AM
Subject: A doubt in RFC 3315

Hi,

Should the Transaction Id must remain the same throughout the
Solicit-Advertise-Request-Reply sequence ?.. or Should there be a
separate transaction id for Solicit-Advertise and a separate transaction
id for Request-Reply ... since you have specified the following under
creation of request message "The client generates a transaction ID and
inserts this value in the "transaction-id" field."

Thanks and regards,

Kasi

------_=_NextPart_001_01C801DB.A2EA33E0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encrtisments'.  One possible alternative is to avoid RAs and use DHCP
for prefix and default router information. 

- Bernie

-----Original Message-----
From: Alain Durand [mailto:[email-masked]] 
Sent: Friday, September 28, 2007 9:57 AM
To: Bernie Volz (volz); RamaSubramanian KrishnaMurthi; [email-masked]
Subject: Re: [dhcwg] DHCPv6 Stateful Prefix Length

    - Alain.

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 28 Sep 2007 16:46:29 +0200

RamaSubramanian KrishnaMurthi wrote:
> Hi all, I don't whether this question has been asked early or not.
> 
> Can the DHCPv6 Stateful server send Prefix length of the IPv6 Address
>  that is being sent to client ? Is there any RFC that talks about ?
> 

Not only _that_ prefix length.

But is there a prefixlength for the 'link-address' field of the
Relay-Forward a Relay sends to Server?  This should be there, in order
for the Server to be able to match the Relay's address/prefixlength on
the subnet clause of the config file in the Server.

If this prefixlen is not there in the Relay-Forw, then the Server can't
know for sure from which subnet does this request come.

In IPv4 this is not a problem, because at the edge of the network, where
  DHCP gives addresses, people don't use CIDR, so the prefix lengths can
be deduced from the address class (eg 192.168 address then netmask 24).

For IPv6 deployments one could assume the edge always uses a prefixlen
/64 but this is not so clean, I think even according to IPv6 Addressing
Architecture.

And... rfc3315 doesn't have that prefixlen, and ISC doesn't it, and
neither WIDE nor Dibbler :-(

Alex

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Fri, 28 Sep 2007 11:15:59 -0400

You don't need a prefix length of the Relay's link-address. That is
complete nonsense.

Just find the configuration item that CONTAINS the address. THIS IS AN
*ADDRESS* not a PREFIX.

If you have two prefixes 1234::/120 and 1234::100/120, you can find
these just fine. For the first one, the link-address would have an
address between 1234:: and 1234::ff. For the second, an address from
1234::100 to 1234::1ff.

- Bernie 

-----Original Message-----
From: Alexandru Petrescu [mailto:[email-masked]] 
Sent: Friday, September 28, 2007 10:46 AM
To: RamaSubramanian KrishnaMurthi
Cc: [email-masked]
Subject: Re: [dhcwg] DHCPv6 Stateful Prefix Length

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 28 Sep 2007 17:38:30 +0200

> Just find the configuration item that CONTAINS the address. THIS IS AN

I agree this 'link-address' is the address of the interface.  But that 
interface has a prefix.

> address between 1234:: and 1234::ff. For the second, an address from

Ok.  How about these two prefixes: 1234::/120 and 1234::10/121.  Where 
would the 'link-address' 1234::10 match?  Why?

Alex

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Fri, 28 Sep 2007 11:50:03 -0400

That's a conflicting configuration, because 1234::/120 contains
1234::10/121.

If you support that, then use the well known rule that LONGEST match
wins (which I assume you'd use anyway).

So, 1234::10 clearly matches 1234::10/121 as it is LONGER than a /120.

If that isn't the answer you want, then DON'T use that as your relay's
link-address. You can set the link-address to 1234::0 to 1234::f if you
want the answer to be 1234::/120.

NOTE: For DHCPv6 we have *NO* IETF DHC WG defined VPN related options at
this time, so you can't have overlapping address spaces. Of course,
you're free to do what you want to support VPNs (and thus overlapping
address spaces) using the vendor specific options or use other data from
the client/relay or your server's configuration to "select" the
appropriate VPN.

- Bernie 

-----Original Message-----
From: Alexandru Petrescu [mailto:[email-masked]] 
Sent: Friday, September 28, 2007 11:39 AM
To: Bernie Volz (volz)
Cc: RamaSubramanian KrishnaMurthi; [email-masked]
Subject: Re: [dhcwg] DHCPv6 Stateful Prefix Length

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 28 Sep 2007 18:12:23 +0200

> That's a conflicting configuration, because 1234::/120 contains

:-) looks as conflicting for that reason but, don't _all_ routable 
prefixes contain the first 3 bits 001?  All prefixes contain some 
prefixes and they're not conflicting.

> wins (which I assume you'd use anyway).

LONGEST match is used for routing mainly, when there's nothing else, I 
agree.

But there are many systems that in addition to longest match use 
hostbased routes and various other ingenious rules for searching in the 
routing table, traffic shaping, tunnelling, and what have you.

> So, 1234::10 clearly matches 1234::10/121 as it is LONGER than a /120.

If longest-match is used then yes.

But I think DHCP shouldn't assume what the underlying routing technology 
uses longest-match.  I'd love it to be so but I'm afraid it isn't.

> want the answer to be 1234::/120.

Right, that would work with longest-match.  But using a precise prefix 
indication would allow the admin to always configure eg ::1 interface id 
  on all Relays' interfaces, no need to think of special Relay cases.

Alex

---

From: "David W. Hankins" <[email-masked]>
Date: Fri, 28 Sep 2007 09:15:32 -0700

> address, then /128 should be assumed.

This is at least inexplicit in the current body of RFCs; but it is
true that an IAADDR, having no prefix information and describing
an address, is itself only a /128.

However, there is an interoperability consideration which suggests
that clients should assume /64 if they wish to work together.

We've discussed this to death on the archives I thought.

-- 
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Fri, 28 Sep 2007 12:40:46 -0400

>that clients should assume /64 if they wish to work together.

No. You are mixing this up with the on-link/not-on-link issue.

All the host can do is add a /128 (and consider that on-link).

Without prefix information, the host must assume other destinations are
not-on-link. If there is a default router, than the host sends the
packet to the router; and the router may send ICMPv6 redirects. If there
is no default router, the host can assume that the destination is
on-link and attempt to communicate with it directly (but that does NOT
mean it can add a /64 or anything else).

I don't see why there would be ANY communication issues. There is no
need for prefix information; it is an optimization to have it and that's
why there are RAs to provide it.

If that doesn't work and a host requires prefix information (and even
worse adds it because of DHCPv6 address assignments), it is not
following IPv6 standards and needs to be fixed.

Before you flame ... The above assumes old RFC 2461/2 behavior and a
simple (one-interface) host because:
1) RFC 4943 breaks this on-link assumption and requires prefix
information in the case where you don't have a router (yuck!). I had
(though too late) suggestd that the on-link assumption ONLY change if
you had a v4 router and no v6 router (as then there was the chance for
DNS to supply unreachable v6 addresses which would cause problems in
communications).
2) For hosts with multiple interfaces there is the issue of which
interface to use and here is where prefix information also becomes
extremely useful (well, technically the routers would hopefull handle it
but communication would not be as efficient as desired if the wrong
router (interface) was chosen). This applies for on-link and not-on-link
addresses.

- Bernie

---

From: "David W. Hankins" <[email-masked]>
Date: Fri, 28 Sep 2007 11:05:30 -0700

> All the host can do is add a /128 (and consider that on-link).

...but since there's no way to do that right now with some deployed
software, it's not really very helpful guidance.

This is all what I meant when I said there are "some interoperabiltity
considerations."

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Fri, 28 Sep 2007 14:33:33 -0400

I guess we're doomed to repeat the same mistakes over and over ...
assuming a fixed/maximum length of subnets/prefixes; other than the
limits of the data itself (0..32 for subnets, 0..128 for prefixes).

- Bernie

---

From: Alain Durand <[email-masked]>
Date: Fri, 28 Sep 2007 15:01:29 -0400

IMHO, the proper way out is to define the prefix length option asap and
agree that, in the transition phase from now to when this this be
implemented, assuming a fixed /64 by default is reasonable.

   - Alain.

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Fri, 28 Sep 2007 15:07:36 -0400

NO! Let's not give people bad advice if they're implementing IPv6.
 
/128 is the reasonable default in the absense of RA PIOs to make it any
longer (or a DHCPv6 option).
 
However, if a host's software is unable to support that and can only do
a /64, I guess the sites with those implementations are stuck with it
and have to live with it. 
 
---
 
For the record, I'm still against such an option.
 
- Bernie

From: Alain Durand [mailto:[email-masked]] 
Sent: Friday, September 28, 2007 3:01 PM
To: Bernie Volz (volz); David W. Hankins; DHC WG
Subject: Re: [dhcwg] DHCPv6 Stateful Prefix Length

   - Alain.

	I guess we're doomed to repeat the same mistakes over and over
...
	assuming a fixed/maximum length of subnets/prefixes; other than
the
	limits of the data itself (0..32 for subnets, 0..128 for
prefixes).
	
	- Bernie
	
	-----Original Message-----
	From: David W. Hankins [mailto:[email-masked]]
	Sent: Friday, September 28, 2007 2:06 PM
	To: DHC WG
	Subject: Re: [dhcwg] DHCPv6 Stateful Prefix Length
	
	On Fri, Sep 28, 2007 at 12:40:46PM -0400, Bernie Volz (volz)
	> All the host can do is add a /128 (and consider that on-link).
	
	...but since there's no way to do that right now with some
deployed
	software, it's not really very helpful guidance.
	
	This is all what I meant when I said there are "some
interoperabiltity
	considerations."
	
	--
	Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
	--
	David W. Hankins        "If you don't do it right the first
time,
	Software Engineer                    you'll just have to do it
again."
	Internet Systems Consortium, Inc.               -- Jack T.
Hankins

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 28 Sep 2007 15:29:09 -0400

I agree with Bernie. /64 was defined for SLAAC hosts as a default and
the length made sense for SLAAC hosts. I won't agree for a /64 for
DHCPv6 hosts as any assumed default. If a DHCPv6 host assumes a /64 when
the host was sent an RA from router with no PIO, then if the host
assumed /64 and host has to forward a packet to a destination that
matches within the /64 length then the host will incorrectly issue an NS
whereas the RA told the host to send the packet to the default router.
 
I am also against such an option.
 
Hemant

From: Bernie Volz (volz) 
Sent: Friday, September 28, 2007 3:08 PM
To: Alain Durand; David W. Hankins; DHC WG
Subject: RE: [dhcwg] DHCPv6 Stateful Prefix Length

 
 
---

- Bernie

   - Alain.

	
	- Bernie

---

From: Alain Durand <[email-masked]>
Date: Fri, 28 Sep 2007 16:05:52 -0400

I could understand your position on the first point. But why would you be
against an option that will tell the DHCPv client what to do when there are
no prefixes in the RA?

   - Alain.

On 9/28/07 3:29 PM, "Hemant Singh (shemant)" <[email-masked]> wrote:

> I agree with Bernie. /64 was defined for SLAAC hosts as a default and the
> length made sense for SLAAC hosts. I won't agree for a /64 for DHCPv6 hosts as
> any assumed default. If a DHCPv6 host assumes a /64 when the host was sent an
> RA from router with no PIO, then if the host assumed /64 and host has to
> forward a packet to a destination that matches within the /64 length then the
> host will incorrectly issue an NS whereas the RA told the host to send the
> packet to the default router.
>  
> /128 is the reasonable default in the absense of RA PIOs to make it any longer
> (or a DHCPv6 option).
>  
> However, if a host's software is unable to support that and can only do a /64,
> I guess the sites with those implementations are stuck with it and have to
> live with it. 
>  
> ---
>  
> IMHO, the proper way out is to define the prefix length option asap and agree
> that, in the transition phase from now to when this this be implemented,
> assuming a fixed /64 by default is reasonable.
> 
>    - Alain.
>

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Fri, 28 Sep 2007 16:32:10 -0400

Not sure if you were asking Hemant or me or both ...
 
My reason is pretty simple ... it is completely unnecessary. RAs already
handle this just fine.
 
If you are going for an option to communicate this, please don't forget
to include the on-link/not-on-link flag!! That is a very important piece
of information that must not be lost. I'd even go as far to suggest that
this option just duplicate the Prefix Information Option that is sent in
the RA, just using DHCPv6 option type/length. That way, if there are
"new" things done for the PIO, they come along in DHCPv6 for free. We
can already support multiple instances of options. So it is very
straightforward. The other benefit of this is that stateless DHCPv6
clients could also use this (and they could generate addresses if the A
bit is set). Of course, for the stateless clients the
Information-Refresh time would have to cause the client to get updated
information before the lifetimes expire.
 
- Bernie

From: Alain Durand [mailto:[email-masked]] 
Sent: Friday, September 28, 2007 4:06 PM
To: Hemant Singh (shemant); Bernie Volz (volz); David W. Hankins; DHC WG
Subject: Re: [dhcwg] DHCPv6 Stateful Prefix Length

I could understand your position on the first point. But why would you
be against an option that will tell the DHCPv client what to do when
there are no prefixes in the RA?

   - Alain.

	I agree with Bernie. /64 was defined for SLAAC hosts as a
default and the length made sense for SLAAC hosts. I won't agree for a
/64 for DHCPv6 hosts as any assumed default. If a DHCPv6 host assumes a
/64 when the host was sent an RA from router with no PIO, then if the
host assumed /64 and host has to forward a packet to a destination that
matches within the /64 length then the host will incorrectly issue an NS
whereas the RA told the host to send the packet to the default router.

	Hemant

	From: Bernie Volz (volz) 
	
	NO! Let's not give people bad advice if they're implementing
IPv6.
	
	/128 is the reasonable default in the absense of RA PIOs to make
it any longer (or a DHCPv6 option).
	
	However, if a host's software is unable to support that and can
only do a /64, I guess the sites with those implementations are stuck
with it and have to live with it. 
	
	---

	- Bernie

	
	IMHO, the proper way out is to define the prefix length option
asap and agree that, in the transition phase from now to when this this
be implemented, assuming a fixed /64 by default is reasonable. 
	
	   - Alain.

		I guess we're doomed to repeat the same mistakes over
and over ...
		assuming a fixed/maximum length of subnets/prefixes;
other  than the
		limits of the data itself (0..32 for subnets, 0..128 for
prefixes).
		
		- Bernie
		
		-----Original Message-----
		From: David W.  Hankins [mailto:[email-masked]]
		Sent:  Friday, September 28, 2007 2:06 PM
		To: DHC WG
		Subject: Re: [dhcwg]  DHCPv6 Stateful Prefix Length
		
		On Fri, Sep 28, 2007 at 12:40:46PM -0400,  Bernie Volz
		> All the host can do is add a /128 (and  consider that
on-link).
		
		...but since there's no way to do that right  now with
some deployed
		software, it's not really very helpful  guidance.

		--
		Ash bugud-gul durbatuluk  agh burzum-ishi krimpatul.
		--
		David W. Hankins         "If you don't do it right the
first  time,
		Software Engineer                     you'll  just have
to do it again."
		Internet Systems Consortium, Inc.                --
Jack T.  Hankins

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 28 Sep 2007 16:35:11 -0400

Alain,
 
Wrt to:

From: Bernie Volz (volz) 
Sent: Friday, September 28, 2007 4:32 PM
To: Alain Durand; Hemant Singh (shemant); David W. Hankins; DHC WG
Subject: RE: [dhcwg] DHCPv6 Stateful Prefix Length

 
 
- Bernie

   - Alain.

	
	
	Hemant

	From: Bernie Volz (volz) 

	
	
	---

	- Bernie

	
	
	   - Alain.

		
		- Bernie

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 28 Sep 2007 16:39:39 -0400

Alain,
 
I already gave my reasoning for "But why would you be against an option
that will tell the DHCPv client what to do when there are no prefixes in
the RA?"
 
If the RA has signalled off-link, sending any prefix length in DHCPv6
option can signal on-link to the host. Why cause such a confusion? Also
how does DHCPv6 server know that the router in the network sent an RA
with no PIO? Now one needs for an admin of the DHCPv6 server and the
router to match setup of the two products. IPv6 has it clean that router
and the RA will provide prefix length information etc. and let DHCPv6
just dole out the address.

Hemant

   - Alain.

	
	
	Hemant

	From: Bernie Volz (volz) 

	
	
	---

	- Bernie

	
	
	   - Alain.

		
		- Bernie

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 28 Sep 2007 16:41:17 -0400

Sorry this one a incomplete email that got sent out accidentally.
Another one has been sent that is complete.
 
Hemant

From: Hemant Singh (shemant) 
Sent: Friday, September 28, 2007 4:35 PM
To: Bernie Volz (volz); Alain Durand; David W. Hankins; DHC WG
Subject: RE: [dhcwg] DHCPv6 Stateful Prefix Length

Alain,
 
Wrt to:

From: Bernie Volz (volz) 

 
 
- Bernie

   - Alain.

	
	
	Hemant

	From: Bernie Volz (volz) 

	
	
	---

	- Bernie

	
	
	   - Alain.

		
		- Bernie

---

From: Alain Durand <[email-masked]>
Date: Fri, 28 Sep 2007 16:43:24 -0400

The reason for asking a DHCPv6 prefix length option has to do with multiple
independent prefixes sharing the same link.

The problem I see with RAs is that any node on such a link will get all
information about all prefixes, even though I may have decided
administratively that nodes do belong to only one prefix at a time (despite
the fact they share the same physical link).

In other words in that independent multi-prefix on the same link scenario ,
RA are good to transmit link (L2) properties, DHCP messages are good to
transmit (L3) prefix information.

   - Alain.

On 9/28/07 4:32 PM, "Bernie Volz (volz)" <[email-masked]> wrote:

> If you are going for an option to communicate this, please don't forget to
> include the on-link/not-on-link flag!! That is a very important piece of
> information that must not be lost. I'd even go as far to suggest that this
> option just duplicate the Prefix Information Option that is sent in the RA,
> just using DHCPv6 option type/length. That way, if there are "new" things done
> for the PIO, they come along in DHCPv6 for free. We can already support
> multiple instances of options. So it is very straightforward. The other
> benefit of this is that stateless DHCPv6 clients could also use this (and they
> could generate addresses if the A bit is set). Of course, for the stateless
> clients the Information-Refresh time would have to cause the client to get
> updated information before the lifetimes expire.
>  
> - Bernie
> 
> 
> against an option that will tell the DHCPv client what to do when there are no
> prefixes in the RA?
> 
>    - Alain.
> 
> 
>> length made sense for SLAAC hosts. I won't agree for a /64 for DHCPv6  hosts
>> as any assumed default. If a DHCPv6 host assumes a /64 when the host was
>> sent an RA from router with no PIO, then if the host assumed /64 and host has
>> to forward a packet to a destination that matches within the /64 length then
>> the host will incorrectly issue an NS whereas the RA told the host to send
>> the  packet to the default router.
>> 
>> However, if a host's software is unable to support that and can  only do a
>> /64, I guess the sites with those implementations are stuck with it  and have
>> to live with it.
>> 
>> ---
>>

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Fri, 28 Sep 2007 16:59:23 -0400

Well, for your environment, no prefix advertisements at all would
actually work best. ICMP redirects can handle the few host-to-host
communications that you would want to allow (mainly those hosts in the
subscriber's home not behind a router). And, if the host operating
systems that do the wrong thing now are fixed to follow the existing
RFCs, you'd be all set.
 
Getting a new DHCPv6 option defined and through the IETF process would
likely be about a year at best; then getting host operating systems to
support it is anyone's guess.
 
So, I think you have much cleaner solution that's available far sooner
already available.
 
- Bernie

From: Alain Durand [mailto:[email-masked]] 
Sent: Friday, September 28, 2007 4:43 PM
To: Bernie Volz (volz); Hemant Singh (shemant); David W. Hankins; DHC WG
Subject: Re: [dhcwg] DHCPv6 Stateful Prefix Length

The reason for asking a DHCPv6 prefix length option has to do with
multiple independent prefixes sharing the same link. 

The problem I see with RAs is that any node on such a link will get all
information about all prefixes, even though I may have decided
administratively that nodes do belong to only one prefix at a time
(despite the fact they share the same physical link).

In other words in that independent multi-prefix on the same link
scenario , RA are good to transmit link (L2) properties, DHCP messages
are good to transmit (L3) prefix information.

   - Alain.

	
	My reason is pretty simple ... it is completely unnecessary. RAs
already handle this just fine.
	
	If you are going for an option to communicate this, please don't
forget to include the on-link/not-on-link flag!! That is a very
important piece of information that must not be lost. I'd even go as far
to suggest that this option just duplicate the Prefix Information Option
that is sent in the RA, just using DHCPv6 option type/length. That way,
if there are "new" things done for the PIO, they come along in DHCPv6
for free. We can already support multiple instances of options. So it is
very straightforward. The other benefit of this is that stateless DHCPv6
clients could also use this (and they could generate addresses if the A
bit is set). Of course, for the stateless clients the
Information-Refresh time would have to cause the client to get updated
information before the lifetimes expire.
	
	- Bernie

	From: Alain Durand [mailto:[email-masked]] 
	Sent: Friday, September 28, 2007 4:06 PM
	To: Hemant Singh (shemant); Bernie Volz (volz); David W.
Hankins; DHC WG
	Subject: Re: [dhcwg] DHCPv6 Stateful Prefix Length
	
	I could understand your position on the first point. But why
would you be against an option that will tell the DHCPv client what to
do when there are no prefixes in the RA?
	
	   - Alain.

	On 9/28/07 3:29 PM, "Hemant Singh (shemant)" <[email-masked]>
wrote:

		I agree with Bernie. /64 was defined for SLAAC hosts as
a default  and the length made sense for SLAAC hosts. I won't agree for
a /64 for DHCPv6  hosts as any assumed default. If a DHCPv6 host assumes
a /64 when the host was  sent an RA from router with no PIO, then if the
host assumed /64 and host has  to forward a packet to a destination that
matches within the /64 length then  the host will incorrectly issue an
NS whereas the RA told the host to send the  packet to the default
router.

		Hemant

		From: Bernie Volz (volz) 
		
		NO! Let's not give people bad advice if they're
implementing IPv6.
		
		/128 is the reasonable default in the absense of RA PIOs
to make it  any longer (or a DHCPv6 option).
		
		However, if a host's software is unable to support that
and can  only do a /64, I guess the sites with those implementations are
stuck with it  and have to live with it. 
		
		---

		- Bernie

		From: Alain Durand
[mailto:[email-masked]]  
		Sent: Friday, September 28, 2007 3:01 PM
		To: Bernie Volz  (volz); David W. Hankins; DHC WG
		Subject: Re: [dhcwg] DHCPv6  Stateful Prefix Length
		
		IMHO, the proper way out is to define the  prefix length
option asap and agree that, in the transition phase from now to  when
this this be implemented, assuming a fixed /64 by default is reasonable.

		   - Alain.
		
		On 9/28/07 2:33 PM, "Bernie Volz  (volz)"
<[email-masked]> wrote:

			I guess we're doomed to repeat the same
mistakes over  and over ...
			assuming a fixed/maximum length of
subnets/prefixes; other  than the
			limits of the data itself (0..32  for subnets,
0..128 for  prefixes).
			
			-  Bernie
			
			-----Original Message-----
			From: David W.  Hankins
[mailto:[email-masked]]
			Sent:   Friday, September 28, 2007 2:06 PM
			To: DHC WG
			Subject: Re:  [dhcwg]  DHCPv6 Stateful Prefix
Length
			
			On Fri, Sep 28, 2007 at  12:40:46PM -0400,
			> All the host can  do is add a /128 (and
consider that on-link).
			
			...but since  there's no way to do that right
now with some deployed
			software,  it's not really very helpful
guidance.
			
			This is all what I meant  when I said there are
"some   interoperabiltity
			considerations."
			
			--
			Ash bugud-gul  durbatuluk  agh burzum-ishi
krimpatul.
			--
			David W. Hankins          "If you don't do it
right  the first  time,
			Software Engineer                      you'll
just have to do it again."
			Internet Systems Consortium, Inc.
--   Jack T.   Hankins

---

From: Alain Durand <[email-masked]>
Date: Fri, 28 Sep 2007 17:32:52 -0400

The ICMP redirect will work but is clearly sub-optimal. Defining the DHCPv6
option will help here, even if it is a year away.

   - Alain.

On 9/28/07 4:59 PM, "Bernie Volz (volz)" <[email-masked]> wrote:

> Well, for your environment, no prefix advertisements at all would actually
> work best. ICMP redirects can handle the few host-to-host communications that
> you would want to allow (mainly those hosts in the subscriber's home not
> behind a router). And, if the host operating systems that do the wrong thing
> now are fixed to follow the existing RFCs, you'd be all set.
>  
> Getting a new DHCPv6 option defined and through the IETF process would likely
> be about a year at best; then getting host operating systems to support it is
> anyone's guess.
>  
> So, I think you have much cleaner solution that's available far sooner already
> available.
>  
> - Bernie
> 
> 
> In other words in that independent multi-prefix on the same link scenario , RA
> are good to transmit link (L2) properties, DHCP messages are good to transmit
> (L3) prefix information.
> 
>    - Alain.
> 
> 
> 
> 
> 
>> just using DHCPv6 option type/length. That way, if there are "new" things
>> done for the PIO, they come along in DHCPv6 for free. We can already support
>> benefit of this is that stateless DHCPv6 clients could also use this (and
>> they  could generate addresses if the A bit is set). Of course, for the
>> stateless  clients the Information-Refresh time would have to cause the
>> client to get  updated information before the lifetimes expire.
>> 
>> - Bernie
>> 
>>  
>> 
>>> length made sense for SLAAC hosts. I won't agree for a /64 for  DHCPv6
>>> hosts as any assumed default. If a DHCPv6 host assumes a /64  when the host
>>> was  sent an RA from router with no PIO, then if the host  assumed /64 and
>>> host has  to forward a packet to a destination that  matches within the /64
>>> length then  the host will incorrectly issue an  NS whereas the RA told the
>>> host to send the  packet to the default  router.
>>> 
>>> /64, I guess the sites with those implementations are stuck  with it  and
>>> have to live with it.
>>> 
>>> ---
>>>

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 28 Sep 2007 17:42:29 -0400

Why is ICMP Redirect sub-optimal? Anyhow, as Bernie is saying, if the
router sent RA with no PIO, then host have to send their non-link-local
traffic to the router, in absence of Redirect and other information
mentioned in draft-wbeebee-on-link-and-off-link-determination-00.txt. If
your environment is a cable aggregation routed deployment then all host
behind modems are always off-link for IPv6 - that's also discussed in
our draft. No Redirects will be sent in such a deployment, let alone
consider Redirects to be sub-optimal in this deployment.
 
If your network is not cable broadband deployment, please let us know
what is it and then let's evaluate your need.
 
Thanks.
 
Hemant

From: Alain Durand [mailto:[email-masked]] 
Sent: Friday, September 28, 2007 5:33 PM
To: Bernie Volz (volz); Hemant Singh (shemant); David W. Hankins; DHC WG
Subject: Re: [dhcwg] DHCPv6 Stateful Prefix Length

The ICMP redirect will work but is clearly sub-optimal. Defining the
DHCPv6 option will help here, even if it is a year away.

   - Alain.

	Well, for your environment, no prefix advertisements at all
would actually work best. ICMP redirects can handle the few host-to-host
communications that you would want to allow (mainly those hosts in the
subscriber's home not behind a router). And, if the host operating
systems that do the wrong thing now are fixed to follow the existing
RFCs, you'd be all set.
	
	Getting a new DHCPv6 option defined and through the IETF process
would likely be about a year at best; then getting host operating
systems to support it is anyone's guess.
	
	So, I think you have much cleaner solution that's available far
sooner already available.
	
	- Bernie

	From: Alain Durand [mailto:[email-masked]] 
	Sent: Friday, September 28, 2007 4:43 PM
	To: Bernie Volz (volz); Hemant Singh (shemant); David W.
Hankins; DHC WG
	Subject: Re: [dhcwg] DHCPv6 Stateful Prefix Length
	
	The reason for asking a DHCPv6 prefix length option has to do
with multiple independent prefixes sharing the same link. 
	
	The problem I see with RAs is that any node on such a link will
get all information about all prefixes, even though I may have decided
administratively that nodes do belong to only one prefix at a time
(despite the fact they share the same physical link).

	   - Alain.

		
		My reason is pretty simple ... it is completely
unnecessary. RAs already handle this just fine.
		
		If you are going for an option to communicate this,
please don't  forget to include the on-link/not-on-link flag!! That is a
very important  piece of information that must not be lost. I'd even go
as far to suggest that  this option just duplicate the Prefix
Information Option that is sent in the  RA, just using DHCPv6 option
type/length. That way, if there are "new" things  done for the PIO, they
come along in DHCPv6 for free. We can already support  multiple
instances of options. So it is very straightforward. The other  benefit
of this is that stateless DHCPv6 clients could also use this (and they
could generate addresses if the A bit is set). Of course, for the
stateless  clients the Information-Refresh time would have to cause the
client to get  updated information before the lifetimes expire.
		
		- Bernie

		From: Alain Durand
[mailto:[email-masked]]  
		Sent: Friday, September 28, 2007 4:06 PM
		To: Hemant Singh  (shemant); Bernie Volz (volz); David
W. Hankins; DHC WG
		Subject: Re:  [dhcwg] DHCPv6 Stateful Prefix Length
		
		I could understand your position on the  first point.
But why would you be against an option that will tell the DHCPv  client
what to do when there are no prefixes in the  RA?
		
		   - Alain.

		On 9/28/07 3:29 PM, "Hemant  Singh (shemant)"
<[email-masked]> wrote:

			I agree with Bernie. /64 was defined for SLAAC
hosts as a default   and the length made sense for SLAAC hosts. I won't
agree for a /64 for  DHCPv6  hosts as any assumed default. If a DHCPv6
host assumes a /64  when the host was  sent an RA from router with no
PIO, then if the host  assumed /64 and host has  to forward a packet to
a destination that  matches within the /64 length then  the host will
incorrectly issue an  NS whereas the RA told the host to send the
packet to the default  router.

			Hemant

			

			From: Bernie Volz (volz) 
			Sent:   Friday, September 28, 2007 3:08 PM
			To: Alain Durand; David  W.  Hankins; DHC WG
			Subject: RE: [dhcwg] DHCPv6 Stateful  Prefix
Length

			/128 is the reasonable default in the absense of
RA PIOs to make  it  any longer (or a DHCPv6 option).
			
			However, if a host's software is unable to
support that and can   only do a /64, I guess the sites with those
implementations are stuck  with it  and have to live with it. 
			
			---
			
			For the record, I'm still against such an
option.
			
			- Bernie

			

			From: Alain Durand
[mailto:[email-masked]]   
			Sent: Friday, September 28, 2007 3:01 PM
			To:  Bernie Volz  (volz); David W. Hankins; DHC
WG
			Subject: Re:  [dhcwg] DHCPv6  Stateful Prefix
Length
			
			IMHO, the proper way out is to define  the
prefix length option asap and agree that, in the transition phase  from
now to  when this this be implemented, assuming a fixed /64 by  default
is reasonable.  
			
			   - Alain.

			 

				I guess we're doomed to repeat the same
mistakes over  and over ...
				assuming a fixed/maximum length  of
subnets/prefixes; other  than the
				limits of the data  itself (0..32  for
subnets, 0..128 for  prefixes).
				
				-   Bernie
				
				-----Original Message-----
				From: David W.   Hankins
[mailto:[email-masked]]
				Sent:    Friday, September 28, 2007 2:06
PM
				To: DHC WG
				Subject:  Re:  [dhcwg]  DHCPv6 Stateful
Prefix Length
				
				On Fri, Sep  28, 2007 at  12:40:46PM
				> All the host can  do is add a /128
(and  consider  that on-link).
				
				...but since  there's no way to do that
right   now with some deployed
				software,  it's not really very  helpful
guidance.
				
				This is all what I meant  when I said
there are "some    interoperabiltity
				considerations."
				
				--
				Ash  bugud-gul  durbatuluk  agh
burzum-ishi krimpatul.
				--
				David  W. Hankins          "If you
don't do it right  the first  time,
				Software Engineer
you'll    just have to do it again."
				Internet Systems Consortium,  Inc.
--    Jack T.    Hankins

---

From: Alain Durand <[email-masked]>
Date: Fri, 28 Sep 2007 18:32:19 -0400

I¹ve read your document with great attention. I think I subscribe to most
points, except that I do not see why you would not use any indications
coming from DHCPv6 to determine if hosts are on link or not...

You could very well say that the semantic of the DHCPv6 option prefix length
information include the notions that all hosts within that prefix are
Œon-link¹.
In deployment case where they would not be, just do not use that option.
Sound simple.

  - Alain.

On 9/28/07 5:42 PM, "Hemant Singh (shemant)" <[email-masked]> wrote:

> Why is ICMP Redirect sub-optimal? Anyhow, as Bernie is saying, if the router
> sent RA with no PIO, then host have to send their non-link-local traffic to
> the router, in absence of Redirect and other information mentioned in
> draft-wbeebee-on-link-and-off-link-determination-00.txt. If your environment
> is a cable aggregation routed deployment then all host behind modems are
> always off-link for IPv6 - that's also discussed in our draft. No Redirects
> will be sent in such a deployment, let alone consider Redirects to be
> sub-optimal in this deployment.
>  
> If your network is not cable broadband deployment, please let us know what is
> it and then let's evaluate your need.
>  
> Thanks.
>  
> Hemant
>  
> 
>> work best. ICMP redirects can handle the few host-to-host  communications
>> that you would want to allow (mainly those hosts in the  subscriber's home
>> not behind a router). And, if the host operating systems  that do the wrong
>> thing now are fixed to follow the existing RFCs, you'd be  all set.
>> 
>>> option just duplicate the Prefix Information  Option that is sent in the
>>> RA, just using DHCPv6 option type/length.  That way, if there are "new"
>>> things  done for the PIO, they come along  in DHCPv6 for free. We can
>>> already support  multiple instances of  options. So it is very
>>> bit is set). Of course, for the stateless   clients the Information-Refresh
>>> time would have to cause the client to  get  updated information before the
>>> lifetimes  expire.
>>> 
>>> - Bernie
>>> 
>>>  
>>>  
>>> 
>>> against an option that will tell the DHCPv  client what to do when  there
>>> are no prefixes in the  RA?
>>> 
>>>    -  Alain.
>>> 
>>> 
>>>> the length made sense for SLAAC hosts. I won't  agree for a /64 for  DHCPv6
>>>> hosts as any assumed default. If a  DHCPv6 host assumes a /64  when the
>>>> host was  sent an RA from  router with no PIO, then if the host  assumed
>>>> /64 and host has   to forward a packet to a destination that  matches
>>>> within the  /64 length then  the host will incorrectly issue an  NS whereas
>>>> the RA told the host to send the  packet to the default   router.
>>>>

---

From: Ralph Droms <[email-masked]>
Date: Fri, 28 Sep 2007 20:21:45 -0400

RamaSubbu - the addresses assigned by DHCPv6 have no associated  
prefix length, so there is no need for including a prefix length with  
those addresses.  According to the model in RFC 4861, addresses  
assigned from interfaces are separate from the on-link prefixes in  
the Prefix List.  The Prefix List is populated by prefix information,  
which includes prefix lengths, carried in PIOs in RAs.  The Prefix  
List is used by the sending algorithm (RFC 4861, sec. 5.2) when a  
host sends an IPv6 datagram.

The idea of associating a prefix length with an assigned address is a  
carryover from IPv4, where there is no mechanism to populate the IPv4  
equivalent of the Prefix List.  In IPv4, the subnet mask is used to  
derive an associated prefix from an assigned address and this prefix  
is assumed to be on-link.  In IPv6, there is no implicit or explicit  
relationship between the addresses assigned to an interface and the  
on-link prefixes in the Prefix List, and the PIOs in RAs explicitly  
carry the information for the Prefix List.

There has been a proposal to provide prefix information to hosts  
through DHCPv6 in addition to RAs.  The correct way to provide that  
information would be to include a list of prefixes and associated  
prefix lengths in the DHCPv6 message sent to the client.  Simply  
associating a prefix length with the assigned addresses would not  
provide the appropriate information to the host.

- Ralph

On Sep 28, 2007, at Sep 28, 2007,1:42 AM, RamaSubramanian  
KrishnaMurthi wrote:

> Address that is being sent to client ? Is there any RFC that talks  
> about ?
>
>   If the DHCPv6 Stateful server doesn't send the prefix length what  
> the prefix value that dhcpv6 stateful client should assume ?
>
>
> Yours ever
> -RamaSubbu SK
>
>
>        
> ______________
> Shape Yahoo! in your own image.  Join our Network Research Panel  
> today!   http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7
>
>
>

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sun, 30 Sep 2007 09:52:01 -0400

Alain,
 
What indication does DHCPv6 is its current form provide to a host to
determine on-link? Nothing! All DHCPv6 provides is an address, not
prefix length. That is why we said what we said in our draft.
 
Do also note ND clearly says in the PIO (Prefix Information Option)
definition section (4.6.2) that even prefix length is not enough to make
an on-link determination. Prefix length has to be combined with the
L-bit in PIO to make an on-link determination.
 
It's a soup if ND and RA use both prefix length and L-bit in PIO to make
on-link determination while your new suggested DHCPv6 prefix length
option is used alone to make on-link determination. Then as Bernie said,
you will have to bring more and more of PIO into DHCPv6 for options.
Bernie has also argued in IETF IPv6 mailer that once both ND RA and
DHCPv6 start doling out the same options and if a host receives
conflicting information, which of DHCPv6 or ND options win?
 
I think I appreciate your problem, but not the solution. We just spent
the last 10 years with ND and DHCPv6 in their current shape and form
where by design DHCPv6 does nor provide any information to make an
on-link determination and it's the router an ND's RA that provides the
on-link information. Given this fundamental design, one cannot just
change DHCPv6 without upsetting or introducing a bug in ND. I already
mentioned one bug in my first reply to this thread where an RA with no
PIO wanted host to send traffic to router while host sees a DHCPv6
option with prefix length and your option told the host to use say, a
/64 for on-link determination - this host could send NS when the host
was signaled by ND that all non-link-local destinations are off-link.
 
Hemant

From: Alain Durand [mailto:[email-masked]] 
Sent: Friday, September 28, 2007 6:32 PM
To: Hemant Singh (shemant); Bernie Volz (volz); David W. Hankins; DHC WG
Subject: Re: [dhcwg] DHCPv6 Stateful Prefix Length

I've read your document with great attention. I think I subscribe to
most points, except that I do not see why you would not use any
indications coming from DHCPv6 to determine if hosts are on link or
not...

You could very well say that the semantic of the DHCPv6 option prefix
length information include the notions that all hosts within that prefix
are 'on-link'.
In deployment case where they would not be, just do not use that option.
Sound simple.

  - Alain.

	Why is ICMP Redirect sub-optimal? Anyhow, as Bernie is saying,
if the router sent RA with no PIO, then host have to send their
non-link-local traffic to the router, in absence of Redirect and other
information mentioned in
draft-wbeebee-on-link-and-off-link-determination-00.txt. If your
environment is a cable aggregation routed deployment then all host
behind modems are always off-link for IPv6 - that's also discussed in
our draft. No Redirects will be sent in such a deployment, let alone
consider Redirects to be sub-optimal in this deployment.
	
	If your network is not cable broadband deployment, please let us
know what is it and then let's evaluate your need.
	
	Thanks.
	
	Hemant

	
	The ICMP redirect will work but is clearly sub-optimal. Defining
the DHCPv6 option will help here, even if it is a year away.
	
	   - Alain.

		Well, for your environment, no prefix advertisements at
all would  actually work best. ICMP redirects can handle the few
host-to-host  communications that you would want to allow (mainly those
hosts in the  subscriber's home not behind a router). And, if the host
operating systems  that do the wrong thing now are fixed to follow the
existing RFCs, you'd be  all set.
		
		Getting a new DHCPv6 option defined and through the IETF
process  would likely be about a year at best; then getting host
operating systems to  support it is anyone's guess.
		
		So, I think you have much cleaner solution that's
available far  sooner already available.
		
		- Bernie

		From: Alain Durand
[mailto:[email-masked]]  
		Sent: Friday, September 28, 2007 4:43 PM
		To: Bernie Volz  (volz); Hemant Singh (shemant); David
W. Hankins; DHC WG
		Subject:  Re: [dhcwg] DHCPv6 Stateful Prefix Length
		
		The reason for asking a DHCPv6 prefix  length option has
to do with multiple independent prefixes sharing the same  link. 
		
		The problem I see with RAs is that any node on such a
link will  get all information about all prefixes, even though I may
have  decided administratively that nodes do belong to only one prefix
at a time  (despite the fact they share the same physical link).
		
		In other words in  that independent multi-prefix on the
same link scenario , RA are good to  transmit link (L2) properties, DHCP
messages are good to transmit (L3) prefix  information.
		
		   - Alain.

		On  9/28/07 4:32 PM, "Bernie Volz (volz)"
<[email-masked]>  wrote:

			Not sure if you were asking Hemant or me or both
...

			If you are going for an option to communicate
this, please don't   forget to include the on-link/not-on-link flag!!
That is a very  important  piece of information that must not be lost.
I'd even go as  far to suggest that  this option just duplicate the
Prefix Information  Option that is sent in the  RA, just using DHCPv6
option type/length.  That way, if there are "new" things  done for the
PIO, they come along  in DHCPv6 for free. We can already support
multiple instances of  options. So it is very straightforward. The other
benefit of this is  that stateless DHCPv6 clients could also use this
(and they  could  generate addresses if the A bit is set). Of course,
for the stateless   clients the Information-Refresh time would have to
cause the client to  get  updated information before the lifetimes
expire.
			
			- Bernie

			

			From: Alain Durand
[mailto:[email-masked]]   
			Sent: Friday, September 28, 2007 4:06 PM
			To:  Hemant Singh  (shemant); Bernie Volz
(volz); David W. Hankins; DHC  WG
			Subject: Re:  [dhcwg] DHCPv6 Stateful Prefix
Length
			
			I could  understand your position on the  first
point. But why would you be  against an option that will tell the DHCPv
client what to do when  there are no prefixes in the  RA?
			
			   -  Alain.

			 

				I agree with Bernie. /64 was defined for
SLAAC hosts as a  default   and the length made sense for SLAAC hosts. I
won't  agree for a /64 for  DHCPv6  hosts as any assumed default. If a
DHCPv6 host assumes a /64  when the host was  sent an RA from  router
with no PIO, then if the host  assumed /64 and host has   to forward a
packet to a destination that  matches within the  /64 length then  the
host will incorrectly issue an  NS whereas  the RA told the host to send
the  packet to the default   router.

				Hemant

				From: Bernie Volz (volz) 
				Sent:    Friday, September 28, 2007 3:08
PM
				To: Alain Durand;  David  W.  Hankins;
DHC WG
				Subject: RE: [dhcwg] DHCPv6  Stateful
Prefix  Length
				
				NO! Let's not give people bad advice if
they're    implementing IPv6.
				
				/128 is the reasonable default in the
absense of RA PIOs to  make  it  any longer (or a DHCPv6  option).
				
				However, if a host's software is unable
to support that and can    only do a /64, I guess the sites with those
implementations  are stuck  with it  and have to live with it.  
				
				---
				
				For the record, I'm still against such
an    option.
				
				- Bernie

				From: Alain Durand
[mailto:[email-masked]]    
				Sent: Friday, September 28, 2007 3:01
PM
				To:  Bernie Volz  (volz); David W.
Hankins; DHC  WG
				Subject: Re:  [dhcwg] DHCPv6  Stateful
Prefix  Length
				
				IMHO, the  proper way out is to define
the  prefix length option asap and  agree that, in the transition phase
from now to  when this this  be implemented, assuming a fixed /64 by
default is reasonable.   
				
				   - Alain.
				
				On  9/28/07 2:33 PM,  "Bernie Volz
(volz)" <[email-masked]>   wrote:

				
				-   Bernie
				
				-----Original  Message-----
				From: David W.   Hankins
[mailto:[email-masked]]
				Sent:     Friday, September 28, 2007
2:06 PM
				To: DHC  WG
				Subject:  Re:  [dhcwg]  DHCPv6 Stateful
Prefix  Length