I guess we can agree to disagree. I think fundamentally keeping the two things completely different will be a far better way for people to think about this. There are implementations that have assumed a /64 for DHCP assigned (or manually configured) addresses when no prefix information was available otherwise. That is clearly wrong. (A /128 is OK.)
I think "subnet mask going along with an interface address is deeply ingrained in the way IP is implemented" is a very true statement for IPv4. Let's not make that same assumption in IPv6, please. --- All I was trying to clarify is that if you want to work in all IPv6 networks, you need BOTH SLAAC and stateful (DHCPv6). If you don't implement both, you may not be able to do much on some networks (because if they are stateless and you don't support that, you won't be able to assign anything but a link-local address; or if they are stateful and you don't suppor that, you may not be able to get a global address). --- In today's world, one would hope that adding a DHCPv6 client would not be adding a significant amount of code. The DHCPv6 client's logic isn't that complex. Sure, it is one more thing to implement and test, but it can't exactly take up a huge amount of memory. - Bernie -----Original Message----- From: Iljitsch van Beijnum [mailto:[EMAIL PROTECTED] Sent: Monday, August 13, 2007 5:56 AM To: Bernie Volz (volz) Cc: Leino, Tammy; ipv6@ietf.org; John Jason Brzozowski (JJMB); [EMAIL PROTECTED] Subject: Re: prefix length determination for DHCPv6 On 11-aug-2007, at 1:39, Bernie Volz ((volz)) wrote: > Interface addresses are completely SEPARATE from routing information. > Please do NOT confuse the two. This has been a source of confusion for > many IPv6 implementors who know IPv4. > The configuration of addresses for an interface MUST NOT be tied to > the > configuration of prefix information for routing. I disagree. For better or for worse, the notion of a subnet mask going along with an interface address is deeply ingrained in the way IP is implemented. Separating the two for no apparent reason is a bad idea. > Just because a prefix > is on a link, does not mean the interface necessarily has an > address for > that prefix (it may have none, 1, or many). Sure, that part is not a problem. > Just because an interface > has an address, does not mean that the system has any prefix > information > for a prefix that "contains" that address. Disagree here. How does it make sense to have an address on an interface and no knowledge about what other systems are directly connected to that interface? Note that "no knowledge" isn't the same thing as "assuming /128". I don't agree with the latter all that much either, but you still know SOMETHING in that case. > And, a node should support both SLACC and DHCPv6 as "The two > methods are > complementary but not mutually exclusive." I'm sure there are cases where DHCPv6 is very useful, but _I_ don't want it on my network. IPv6 specifications and implementations without DHCPv6 have been around for the better part of a decade, so requiring DHCPv6 now seems curious at best. In other words: DHCPv6 should be optional. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
