Subject: RE: prefix length determination for DHCPv6

From: "Leino, Tammy" <[email-masked]>
Date: Fri, 10 Aug 2007 17:28:17 -0500

Thank you John.

Has your working group considered adding this as a DHCPv6 option?  If the on-link router is not configured to transmit RAs, a DHCPv6 option advertising the default gateway would be helpful in populating the routing table.

Best Regards,
Tammy

-----Original Message-----
From: John Jason Brzozowski (JJMB) [mailto:[email-masked]]
Sent: Friday, August 10, 2007 6:20 PM
To: Hemant Singh (shemant); Leino, Tammy; [email-masked]
Subject: RE: prefix length determination for DHCPv6

Hello Hemant,

There is no DHCPv6 mechabism to explicitly transmit router/gateway information.

Regards,

John
######################
John Jason Brzozowski, CISSP, RHCT
[email-masked]
484-994-6787
######################

-----Original Message-----
From: "Hemant Singh (shemant)" <[email-masked]>
To: "Leino, Tammy" <[email-masked]>; [email-masked]
Sent: 08/10/07 18:14
Subject: RE: prefix length determination for DHCPv6

________________________________

From: Leino, Tammy [mailto:[email-masked]] 
Sent: Friday, August 10, 2007 5:56 PM
To: [email-masked]
Subject: prefix length determination for DHCPv6

Hello, 

In implementing RFC 3315, I see no option or field in the IA_NA option
for a prefix length associated with an assigned IPv6 address.  How does
the client determine the prefix length of the IPv6 address the server is
assigning? 

<hs> One way to to send a Prefix Information Option (PIO) for the
assigned address prefix in RA to the client.  PIO includes prefix
length.

</hs>

Furthermore, in the absence of a configured IPv6 router on the link, can
the client use the DHCPv6 server to find a default gateway out of the
local network?  

<hs> I don't believe so. I'll let the DHCPv6 RFC authors like Ralph
Droms and Bernie Volz verify this one. 

</hs>

Hemant

  If so, what RFC specifies this option?

Any help or referrals to additional RFCs would be much appreciated. 

Best Regards, 
Tammy Leino 

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 11 Aug 2007 00:51:49 +0200

On 11-aug-2007, at 0:28, Leino, Tammy wrote:

> Has your working group considered adding this as a DHCPv6 option?   
> If the on-link router is not configured to transmit RAs, a DHCPv6  
> option advertising the default gateway would be helpful in  
> populating the routing table.

The problem with that would be that you either have to wait for some  
time to be sure that there are no RAs, or you need to initiate DHCPv6  
always immediately. The former leads to delays for the user, the  
latter to additional network chatter which would be unnecessary in  
most situations. Worse, the extra chatter is multicast, I'm again  
stressing that multicasts take up inordinate amounts of bandwidth on  
wifi networks.

So I don't think we should present NOT having RAs as a valid  
configuration option. This way, we get to avoid the situations above.  
If people want to configure hosts using DHCPv6 they should have  
routers send out RAs with the M bit set and with no prefix information.

Note that currently, it's not possible to distribute default gateway  
information through DHCPv6, so RAs would also have to be used for that.

(There is of course the consideration that at this time, very few  
IPv6 implementations can configure an address through DHCPv6.)

Strange that a subnet size isn't included with the DHCPv6 address  
assignment. I guess this means either configuring a /128 and rely on  
router redirects to learn about directly attached neighbors, or use  
RFC 3513 as your guideline and make it /64:

    For all unicast addresses, except those that start with binary value
    000, Interface IDs are required to be 64 bits long and to be
    constructed in Modified EUI-64 format.

By the way, I would very much like to know who came up with that  
requirement and why.

---

From: "Leino, Tammy" <[email-masked]>
Date: Fri, 10 Aug 2007 18:09:32 -0500

Thank you very much for your comments.

The reason I am not assuming there is a router on link configured to
send RAs with prefix options is because I don't see the point of DHCPv6
configuring addresses if a router is configured to do the same job.
Since the prefix length is carried in a prefix option of an RA, I have
to assume these will be absent on the link; otherwise, the node would
not be using DHCPv6 to obtain an address.  Furthermore, the DoD Base
Requirements for an IPv6 Capable Node also does not assume this to be
the case:

"All IPv6 Nodes MUST support at least one autonomous method for
discovering its own unique IPv6 interface address(es), either RFC 2462,
IPv6 Stateless Address Auto-configuration (SLAAC) or the client side of
RFC 3315, DHCPv6.  DHCPv6 provides for a stateful equivalent to SLAAC.
The two methods are complementary but not mutually exclusive."

Is this because of some shortcoming(s) in the specification or do
network managers find DHCPv6 unnecessary?  If they are not using DHCPv6,
how do they distribute DNS servers and other configuration information?
I am interested in learning how well received DHCPv6 has been.  We have
been slow to implement it in our OS because of low demand.

Thank you for this advice.  I would like to request to the working group
that a new option be introduced to DHCPv6 that specifies a prefix length
either for an IA_NA or just a single IA_ADDR.  In the meantime, I will
take your advice.

Best Regards,
Tammy

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Fri, 10 Aug 2007 19:19:45 -0400

The PIOs in an RA tells a node whether it can autoconfigure or not via
the A bit. If the A bit is not set, the node can not use SLAAC. But, it
CAN use the PIO information to build the table of what prefixes exist
and which are on-link.

That is why there is no need for DHCPv6 to provide default router and
prefix information because the RA does that.

Having two ways (DHCPv6 and RA) provide this information is just asking
for a lot of trouble. What if they conflict each other? Who wins?

And, if there are no routers, there's no need for anything but
link-local addresses (since you can't get off the local link).

It is far better to have the device that is providing the service (ie,
the router which is providing routing services) provide this type of
information.

- Bernie

-----Original Message-----
From: Leino, Tammy [mailto:[email-masked]] 
Sent: Friday, August 10, 2007 7:10 PM
To: Iljitsch van Beijnum
Cc: [email-masked]; John Jason Brzozowski (JJMB)
Subject: RE: prefix length determination for DHCPv6

Best Regards,
Tammy

---

From: "Leino, Tammy" <[email-masked]>
Date: Fri, 10 Aug 2007 18:28:27 -0500

Thank you Bernie.

In my example case, there is a forwarding router on link, but the router
is not configured to send RAs.  The DoD seems to think a network can use
(DHCPv6 || RAs) || (DHCPv6 && RAs).

The RA should be received before DHCPv6 is even invoked.  The node
should not invoke DHCPv6 unless the RA tells the node to do so, the user
tells the node not to use the RA, or there are no RAs on link.

If there is DHCPv6 but no RA, who tells me my prefix length?

Best Regards,
Tammy

-----Original Message-----
From: Bernie Volz (volz) [mailto:[email-masked]]
Sent: Friday, August 10, 2007 7:20 PM
To: Leino, Tammy; Iljitsch van Beijnum
Cc: [email-masked]; John Jason Brzozowski (JJMB); [email-masked]
Subject: RE: prefix length determination for DHCPv6

- Bernie

-----Original Message-----
From: Leino, Tammy [mailto:[email-masked]] 
Sent: Friday, August 10, 2007 7:10 PM
To: Iljitsch van Beijnum
Cc: [email-masked]; John Jason Brzozowski (JJMB)
Subject: RE: prefix length determination for DHCPv6

Best Regards,
Tammy

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Fri, 10 Aug 2007 19:39:16 -0400

If this is true, the DoD is sadly mistaken. But, I think you are not
understanding the statement correctly. The quoted statement says nothing
about RAs - it talks about discovering interface addresses.

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. 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). Just because an interface
has an address, does not mean that the system has any prefix information
for a prefix that "contains" that address. Prefix information and
addresses assigned to interfaces are completely separate.

And, a node should support both SLACC and DHCPv6 as "The two methods are
complementary but not mutually exclusive."

A full IPv6 node needs:
- RAs for prefix information and default router information.
- SLAAC for auto-generating addresses for prefixes on which the A-bit is
set.
- DHCPv6 if the M and/or O bits are set.

Missing any of these means you can not operate on all IPv6 networks, or
you might have limited service capabilities on some.

- Bernie

-----Original Message-----
From: Leino, Tammy [mailto:[email-masked]] 
Sent: Friday, August 10, 2007 7:28 PM
To: Bernie Volz (volz); Iljitsch van Beijnum
Cc: [email-masked]; John Jason Brzozowski (JJMB); [email-masked]
Subject: RE: prefix length determination for DHCPv6

Thank you Bernie.

Best Regards,
Tammy

-----Original Message-----
From: Bernie Volz (volz) [mailto:[email-masked]]
Sent: Friday, August 10, 2007 7:20 PM
To: Leino, Tammy; Iljitsch van Beijnum
Cc: [email-masked]; John Jason Brzozowski (JJMB); [email-masked]
Subject: RE: prefix length determination for DHCPv6

- Bernie

-----Original Message-----
From: Leino, Tammy [mailto:[email-masked]] 
Sent: Friday, August 10, 2007 7:10 PM
To: Iljitsch van Beijnum
Cc: [email-masked]; John Jason Brzozowski (JJMB)
Subject: RE: prefix length determination for DHCPv6

Best Regards,
Tammy

---

From: "Leino, Tammy" <[email-masked]>
Date: Fri, 10 Aug 2007 18:55:18 -0500

Thank you Bernie.  I appreciate your advice.

When I add an address in my OS, I add a network route according to the
prefix length of the address so I know that other nodes with this same
prefix are on-link.  I don't route based on a source address.  I find a
route for a destination from the routing table based on the destination
address.  If I added a network route for my prefix, and this destination
matches that prefix, then I find that network route.  Otherwise, I find
the default route and use it.  If I receive a redirect, I will create a
host route for that destination.  If I had been able to add a network
route, I never would have received that redirect and would be saving
memory by not adding the host route.  Can you tell I work on embedded
systems?  I am very stingy with memory!

I will not have a route for a prefix if I do not have an address
assigned to a local interface containing based on that prefix.  If an
address associated with a prefix is deleted, so is the route.

I appreciate everyone's comments and advice.  I am glad to see such
passion for IPv6 and support of people in need.

I just want to voice my opinion that I feel a DHCPv6 prefix length
option and default router option would be useful.

Best Regards,
Tammy

-----Original Message-----
From: Bernie Volz (volz) [mailto:[email-masked]]
Sent: Friday, August 10, 2007 7:39 PM
To: Leino, Tammy; Iljitsch van Beijnum
Cc: [email-masked]; John Jason Brzozowski (JJMB); [email-masked]
Subject: RE: prefix length determination for DHCPv6

A full IPv6 node needs:

- Bernie

-----Original Message-----
From: Leino, Tammy [mailto:[email-masked]] 
Sent: Friday, August 10, 2007 7:28 PM
To: Bernie Volz (volz); Iljitsch van Beijnum
Cc: [email-masked]; John Jason Brzozowski (JJMB); [email-masked]
Subject: RE: prefix length determination for DHCPv6

Thank you Bernie.

Best Regards,
Tammy

-----Original Message-----
From: Bernie Volz (volz) [mailto:[email-masked]]
Sent: Friday, August 10, 2007 7:20 PM
To: Leino, Tammy; Iljitsch van Beijnum
Cc: [email-masked]; John Jason Brzozowski (JJMB); [email-masked]
Subject: RE: prefix length determination for DHCPv6

- Bernie

-----Original Message-----
From: Leino, Tammy [mailto:[email-masked]] 
Sent: Friday, August 10, 2007 7:10 PM
To: Iljitsch van Beijnum
Cc: [email-masked]; John Jason Brzozowski (JJMB)
Subject: RE: prefix length determination for DHCPv6

Best Regards,
Tammy

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Sat, 11 Aug 2007 17:51:09 +0900

At Fri, 10 Aug 2007 18:55:18 -0500,

> passion for IPv6 and support of people in need.

You still seem to be confused about the notion of separation between
address configuration and on-link prefix configuration that Bernie
already explained pretty well.  It should also be remarked that prefix
information provided by RA does not always mean address configuration
(which, again, Bernie already explained).  If one understood these
points, we could easily understand the following quote of the DoD
requirement doesn't actually indicate the need for on-link prefix
information given by DHCPv6:

  "All IPv6 Nodes MUST support at least one autonomous method for
  discovering its own unique IPv6 interface address(es), either RFC
  2462, IPv6 Stateless Address Auto-configuration (SLAAC) or the
  client side of RFC 3315, DHCPv6.  DHCPv6 provides for a stateful
  equivalent to SLAAC.  The two methods are complementary but not
  mutually exclusive."

That is, it only talks about address configuration but doesn't say
anything about on-link prefix information.

Overall, we should first share the base understanding of the protocol
design before discussing anything new.

Assuming we share the base, points to be discussed are:

- whether we need a way to provide on-link prefix information via
  DHCPv6 even if RA already has this provision.  I don't see strong
  need for this; however, as David mentioned there is a minor void due
  to the deprecation of the "on-link by default" rule, and I agree it
  at least warrants discussion on the need for this new option.  But
  even if we introduce the new option I believe it should only cover
  very rare cases and host implementation should not assume this
  information is always provided via DHCPv6.

- whether we need a way to provide default router addresses via DHCPv6
  even if RA already has this provision.  I personally don't see any
  need for this unlike the case of on-link prefix information.  For
  that matter, simply saying "there may be a case where there is a
  node that forward packets but don't send out RAs" isn't convincing
  enough to me (and I'm afraid not to many others).  A reasonable
  background should also be provided that explains why we ever need
  such a seemingly unrealistic scenario.  Again, just saying some
  authority like DoD is requiring something isn't convincing to me
  ,and I'm afraid not to many others; besides, as explained above the
  DoD statement talking about address configuration methods doesn't
  justify the need for this new option in the first place.

In any event, I hear that some DHCPv6 guys are planning to make a new
draft that covers this topic.  So I think it's better to hold off for
now and wait for the document, rather than continue this thread
with keeping possible misunderstanding or confusing about the base
protocol principles.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

---

From: Ralph Droms <[email-masked]>
Date: Sat, 11 Aug 2007 06:28:32 -0400

This issue was discussed in the dhc and v6ops WGs at the last IETF  
meeting: http://www3.ietf.org/proceedings/07jul/slides/dhc-5.pdf

- Ralph

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 11 Aug 2007 21:26:44 +0900

> passion for IPv6 and support of people in need.

You shouldn't.

You SHOULD remember that ND is *NOT* mandately for IPv6.

ND is, despite a lot of effort to fix it in some limited cases (an
obvious example is "7.5.  Changes to Sending Router Advertisements"
of RFC 3775), so broken that even people having passion for IPv6 can
not dare to say to mandate ND.

ND is a poorly designed protcol designed by a committee named IETF.

Instead, any IPv6 related protocols, including DHCP, should consider
*LUCKY* hosts on links *WITHOUT* any ND.

> option and default router option would be useful.

Prefix length is a health idea.

However, unfortunately for you, the concept of "default router", which
is developped by a committee named IETF, is a fatal violation of the
end to end principle of the Internet.

That is, end nodes of the Internet, definitely not so-called default
routers adjacent to them, MUST directly control the communication
without being bothered by so-called default routers.

To avoid fatal dameges of ND on links using ND, you can make your
host a router, though it will cause other problems (using default
route to shrink a routing table is another violation of the end to
end principle, which requires solutions not addressed by IPv6).

						Masataka Ohta

PS

FYI, the current multicast specification is as broken as ND that you
should avoid both of them. Eg, broken multicast requires full of
configurations that DHCP should avoid them.

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Sat, 11 Aug 2007 22:43:36 +0900 (JST)

> You SHOULD remember that ND is *NOT* mandately for IPv6.

	just for clarification - which part of ND (RS/RA, NS/NA, or something
	else), and under which condition?

itojun

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 13 Aug 2007 11:55:46 +0200

> 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
> that prefix (it may have none, 1, or many).

Sure, that part is not a problem.

> Just because an interface
> 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.

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

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 13 Aug 2007 12:17:33 +0200

> configuring addresses if a router is configured to do the same job.

:-)

> not be using DHCPv6 to obtain an address.

But then, why do you need addresses when you have no external  
connectivity? A lot of stuff will work just fine over link local  
addresses, although the need to include a scope identifier gets in  
the way of some applications.

> network managers find DHCPv6 unnecessary?

First of all, the DHCPv6 specification was finished relatively late,  
in 2003 if I'm not mistaken. Most major vendors had already  
implemented IPv6 by then and I'm guessing that deployment levels so  
far haven't exactly given them much reason to drastically update  
their IPv6 implementations.

Then there is the confusion about stateful and stateless DHCPv6 and  
the whole discussion about the meaning of the M and O bits in router  
advertisements. I think this created uncertainty in the market place  
for some time.

Since address configuration has always happened and continues to  
happen through stateless autoconfiguration, DHCPv6 address assignment  
wasn't implemented widely, and you can only use this mechanism when  
you can be sure that both the server and the clients support it. It  
looks like now that IPv6 is gaining more widespread attention that  
more people want this because it's the same as in IPv4, but "old  
school" IPv6 users are generally happy with stateless autoconfiguration.

That leaves:

> If they are not using DHCPv6,

In practice? They don't. As long as you have IPv4, you can use IPv4  
for this.

Other than that, you mostly manually configure an address. Although  
DHCPv6 allows you to do this automatically, the trouble is that you  
can't be sure that there will be a DHCPv6 server everywhere you go so  
in practice, the advantage of DHCPv6 over manual configuration is  
limited. There was talk about using well-known anycasted addresses  
for this but that never came off the ground.

In the near future we'll have draft-jeong-dnsop-ipv6-dns- 
discovery-12.txt which is now in the RFC Editor queue. However, this  
will have the same problem as DHCPv6: you can't be sure that someone  
is making the info available until it's extremely widely implemented.

> been slow to implement it in our OS because of low demand.

My opinion: DHCPv6 is a complex protocol that uses a relatively high  
number of messages. In the past, UDP-based protocols have been  
especially susceptible to security problems in their implementations.  
As such, I'm very happy to do without it when I don't need it and I  
feel stronly that DHCPv6 should NOT be initiated by clients by  
default but only if RA flags indicate that they should do this, and  
DNS configuration should be possible without DHCPv6.

Having said that, there can be situations where it's useful to assign  
an address to an IPv6 host, so there is certainly a place for DHCPv6.  
And prefix delegation is brilliant, this is a great way to provision  
IPv6 CPEs with an address block.

---

From: "Leino, Tammy" <[email-masked]>
Date: Mon, 13 Aug 2007 08:19:30 -0500

Iljitsch, thank you for your comprehensive remarks.  I think my mistake
was in believing an IPv6 router does not have to be configured to send
RAs, but the DHCPv6 server could serve the same purpose as the RAs.  It
appears DHCPv6 was meant to supplement RAs.

As an embedded developer, there is a lot of overhead in terms of code
space and memory requirements in the DHCPv6 protocol, particularly for
customers wishing to just distribute DNS servers.  It would be nice if
all the configuration options of DHCPv6 had been added to RAs.  This
way, we would save on memory.

Thank you again for your time and advice.

Best Regards,
Tammy

-----Original Message-----
From: Iljitsch van Beijnum [mailto:[email-masked]]
Sent: Monday, August 13, 2007 6:18 AM
To: Leino, Tammy
Cc: John Jason Brzozowski (JJMB); Hemant Singh (shemant); [email-masked]
Subject: Re: prefix length determination for DHCPv6

:-)

---

From: "Leino, Tammy" <[email-masked]>
Date: Mon, 13 Aug 2007 08:20:41 -0500

I agree with all your remarks Iljitsch, and I believe my customers feel
the same way as you.

-----Original Message-----
From: Iljitsch van Beijnum [mailto:[email-masked]]
Sent: Monday, August 13, 2007 5:56 AM
To: Bernie Volz ((volz))
Cc: Leino, Tammy; [email-masked]; John Jason Brzozowski (JJMB);
[email-masked]

---

From: James Carlson <[email-masked]>
Date: Mon, 13 Aug 2007 11:38:57 -0400

> IP is implemented. Separating the two for no apparent reason is a bad  

There's a problem with that idea.  There's no guarantee in any
deployment that the DHCPv6 server is actually the definitive source of
information about the prefixes that are on the link.  Routers are
supposed to be that source in IPv6 (via RAs), and DHCPv6 servers
needn't also be routers.

If you were to add an option to DHCPv6 to transfer routing-related
data (including prefixes and default router addresses), you'd have to
invent some way to keep the DHCPv6 server information in sync with the
actual set of routers on the network.  Otherwise, you're relying on
manual configuration of the DHCPv6 server that's continuously tweaked
to match the routers.

For that reason, I oppose adding this information to DHCPv6.  Unlike
IPv4, I think the DHCPv6 designers got this choice _right_.  For the
sake of consistency, should only be _one_ source of authoritative
information, and for prefixes and routes on hosts, RAs are it.

> either, but you still know SOMETHING in that case.

All that you know from DHCPv6 is the address.

> requiring DHCPv6 now seems curious at best. In other words: DHCPv6  

I think implementation of DHCPv6 can certainly be required by
consumers, including the DoD.  All they have to say is, "I don't care
what's optional in the RFC; I just won't buy any gear that doesn't
support this list of features, including DHCPv6."

Deployment and use of it, of course, is up to individual network
administrators, and is by no means required.

> appears DHCPv6 was meant to supplement RAs.

Exactly.

> way, we would save on memory.

I think that's a mistake.

First of all, listening to RAs is no more expensive than listening to
DHCPv6 messages.  If you really feel compelled to do so, then have
your DHCPv6 implementation send RSes when setting up a new address,
and listen to the RAs and store the prefixes where they're handy.

Secondly, designing protocols to fit the limitations of today's
hardware (or, worse, the _perceived_ limitations) is an error.
Protocols last a long time, but hardware does not.  Consider, for
example, that IPv4 discussions were held over 30 years ago, when
common small computers had just a few KB of memory.

The skill in embedded implementation is in saving on memory where you
can without compromising integrity of the external interfaces.

Protocols last long enough that today's problems, unless they're
intrinsic, ought to be taken with a grain of salt.  And, yes, despite
my current employer address, my background (for the past 20 years or
so) has been in embedded systems as well.

-- 
James Carlson, Solaris Networking              <[email-masked]>
Sun Microsystems / 1 Network Drive         71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

---

From: "Wes Beebee \(wbeebee\)" <[email-masked]>
Date: Mon, 13 Aug 2007 11:48:38 -0400

As Bernie said, having two ways of doing the same thing, for example
having 
both the RA and DHCPv6 determine the default gateway or on-link
information, 
leads to both confusion and conflicts.  Which one do you believe?  If
you're 
talking about security, both RA's and DHCPv6 can be spoofed - so adding 
redundant and conflicting information solves nothing.

Others can argue that either ND (RA's) or DHCPv6 can be abolished - but 
I would argue that separating concerns, like on-link/routing information

from address acquisition actually gives you more freedom to design your 
network the way you want to in a very clean, and easily understandable
way.  For instance, you may choose to have two completely different 
approaches to doling out address information (in a central repository or
DHCPv6 server, where you can easily control who gets to have access to
the
network), from routing/on-link information which is associated with the
topology of the network and should be made consistent with the routing
tables
in the routers that manage that network.  If the information is managed
and accessable from two different sources, then it makes sense to have
two different mechanisms for managing that information.  If you have two
different mechanisms, then they should be orthogonal and cleanly
separate
concerns to avoid conflicts and confusion.

Just because "that's the way they did it in IPv4" is not a good reason
to
do it in IPv6 - we're supposed to be using the opportunity which is
given
to us by the total network upgrade to IPv6 in order to designing a
better 
system than IPv4.

- Wes Beebee

-----Original Message-----
From: Ralph Droms (rdroms) 
Sent: Saturday, August 11, 2007 6:29 AM
To: Leino, Tammy
Cc: [email-masked]; John Jason Brzozowski (JJMB)
Subject: Re: prefix length determination for DHCPv6

- Ralph

On Aug 10, 2007, at Aug 10, 2007,6:28 PM, Leino, Tammy wrote:

> option advertising the default gateway would be helpful in populating 
> the routing table.
>
> Best Regards,
> Tammy
>
>
>

> for a prefix length associated with an assigned IPv6 address.  How 
> does the client determine the prefix length of the IPv6 address the 
> server is assigning?
>
> Furthermore, in the absence of a configured IPv6 router on the link, 
> can the client use the DHCPv6 server to find a default gateway out of 
> the local network?
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 13 Aug 2007 19:06:08 +0200

Leino, Tammy wrote:
> Iljitsch, thank you for your comprehensive remarks.  I think my
> mistake was in believing an IPv6 router does not have to be
> configured to send RAs, but the DHCPv6 server could serve the same
> purpose as the RAs.  It appears DHCPv6 was meant to supplement RAs.
> 
>  space and memory requirements in the DHCPv6 protocol, particularly
> for customers wishing to just distribute DNS servers.  It would be
> nice if all the configuration options of DHCPv6 had been added to
> RAs.  This way, we would save on memory.

Errr... the RAs would become larger and bandwidth would be wasted sometimes.

I'd rather extend the RA to include the DHCP Server address such that
the mobile does not need to discover the DHCP Server address, thus
gaining time by eliminating Solicit and Advertise DHCP messages.

But these things are relatively widely implemented and modifying
anything in the existing operation risks taking a lot of time...

Alex

> Best Regards, Tammy
> -----Original Message----- From: Iljitsch van Beijnum
> [mailto:[email-masked]] Sent: Monday, August 13, 2007 6:18 AM To:
> Leino, Tammy Cc: John Jason Brzozowski (JJMB); Hemant Singh
> (shemant); [email-masked] Subject: Re: prefix length determination for
> DHCPv6
> 
> 
>> The reason I am not assuming there is a router on link configured
>> to send RAs with prefix options is because I don't see the point of
>>  DHCPv6 configuring addresses if a router is configured to do the
>> same job.
> 
> :-)
> 
>> Since the prefix length is carried in a prefix option of an RA, I
>> have to assume these will be absent on the link; otherwise, the
>> node would not be using DHCPv6 to obtain an address.
> 
>> If they are not using DHCPv6, how do they distribute DNS servers
>> and other configuration information?
> 
>  can't be sure that there will be a DHCPv6 server everywhere you go
> so in practice, the advantage of DHCPv6 over manual configuration is
>> I am interested in learning how well received DHCPv6 has been.  We
>>  have been slow to implement it in our OS because of low demand.
> 
>  an address to an IPv6 host, so there is certainly a place for
> DHCPv6. And prefix delegation is brilliant, this is a great way to
> provision IPv6 CPEs with an address block.
> 
> IETF IPv6 working group mailing list [email-masked] Administrative
> Requests: https://www1.ietf.org/mailman/listinfo/ipv6 

______________________________________________________________________
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: Mon, 13 Aug 2007 13:25:42 -0400

DHCP server address would be useless because clients don't generally
unicast to the server/relay (and aren't allowed to unless the server has
sent a server-unicast option). And, if the server isn't on-link, unless
the client has an address of sufficient scope, it couldn't communicate
with the server directly.

And, what value does this add anyway?

If you are trying to get just get DNS server addresses, you can use
Information-Request (which is multicast) and you'll get the answer in a
Reply (which is unicast).

So, you add two messages - only one of which is multicast.

Even if you do use address assignment and thus Solicit, you can include
the Rapid Commit option which can save two messages (instead of
Solicit/Advertise/Request/Reply, you have Solicit/Reply). Only the
client's messages are multicast.

DHCPv6 messages are generally small and don't require a lot of back and
further. I really don't understand why people are objecting to one or
two request/reply exchanges (only the request of which is multicast).
Sure, it be nice if there were zero messages, but we're basically down
to as few as possible and most of these messages are tiny (especially
compared to the 300+ bytes that is the minimal size of DHCPv4 messages).

- Bernie 

-----Original Message-----
From: Alexandru Petrescu [mailto:[email-masked]] 
Sent: Monday, August 13, 2007 1:06 PM
To: Leino, Tammy
Cc: Iljitsch van Beijnum; [email-masked]; John Jason Brzozowski (JJMB)
Subject: Re: prefix length determination for DHCPv6

> RAs.  This way, we would save on memory.

Errr... the RAs would become larger and bandwidth would be wasted
sometimes.

Alex

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Mon, 13 Aug 2007 13:31:58 -0400

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-masked]] 
Sent: Monday, August 13, 2007 5:56 AM
To: Bernie Volz (volz)
Cc: Leino, Tammy; [email-masked]; John Jason Brzozowski (JJMB);
[email-masked]

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 13 Aug 2007 20:24:08 +0200

On 13-aug-2007, at 17:38, James Carlson wrote:

>> For better or for worse, the notion of a subnet mask

> supposed to be that source in IPv6 (via RAs), and DHCPv6 servers

That may very well be, but if DHCP servers give out addresses, then  
this particular can of worms is already open and you have to deal  
with it. I.e., the only way a host is going to be able to use the  
address it got from the DHCP server, is if at least one router knows  
to send packets for that address to the host in question. The  
traditional way for routers to know this is to make sure that the  
addresses given to a host (through DHCP or other means) fall within  
the (well, a) subnet configured on the router's interface that the  
host connects to.

Now if we can manage for all that to happen correctly, why not finish  
the job and tell the host about the subnet size?

> For that reason, I oppose adding this information to DHCPv6.

I can go along with that for the most part.

> Unlike

Well, if you want consistency, you'll have to look elsewhere, because  
having DHCPv6 servers tell hosts their addresses breaks exactly this  
separation.

There are two reasons that I can think of to have a DHCPv6 server  
assign addresses:

1. Because it's desireable for the host to have an address that's  
based on information that the host itself doesn't know (for instance,  
a hash based address for shim6 proxy operation)

2. For authentication, authorization and control. I.e., as an ISP, I  
want to know which IPv6 belongs to which customer. The interesting  
part here is that it's not necessary for the DHCPv6 server to come up  
with the address. What we need is that some central server learns  
about all the addresses. The crucial difference here is that handing  
out addresses has the potential for routing problems, while learning  
addresses that the host got through other means (probably stateless  
autoconf) is just as useful but without the potential for trouble

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 13 Aug 2007 20:26:47 +0200

> compared to the 300+ bytes that is the minimal size of DHCPv4  

It adds up if you have a large number of hosts on a subnet.

Which got me thinking: wouldn't it be great if a single message from  
a host could serve as both a router solicitation and a DHCP solicit  
message?

---

From: Ralph Droms <[email-masked]>
Date: Mon, 13 Aug 2007 14:46:00 -0400

Following up on Bernie's comments about DHCPv6 for non-address  
configuration information, take a look at RFC 3736, "stateless DHCP  
Service for IPv6" (ftp://ftp.rfc-editor.org/in-notes/rfc3736.txt) for  
a summary of the minimal implementation and deployment needed for  
DHCPv6 as a complement to SLAAC.

And, as David points out, it's perfectly feasible to colocate a  
DHCPv6 server with a router.  IOS includes a DHCPv6 server, currently  
providing Information Request (RFC 3736) and Prefix Delegation (RFC  
3633) services.  I was involved with the implementation of the  
Information Request service; trust me, it's *quite* simple.

- Ralph

---

From: James Carlson <[email-masked]>
Date: Tue, 14 Aug 2007 08:54:13 -0400

Iljitsch van Beijnum writes:
> with it.

Not exactly.

If they provide addresses (they needn't do so), then they need to be
configured with lists and/or ranges of addresses to provide.  They
don't need to know about the full prefix extent, nor do they need to
know the IP addresses of the operable IPv6 routers on the network.

You're right that the lists of addresses are administratively related
to the prefixes, but they're not the same thing.  In fact, it's
possible for the two to be in different administrative hands -- one
group responsible for routing, and the other for address assignment
and configuration parameters.

A modified DHCPv6 protocol that hands out prefixes and default routes
(in order to subsume RA's role) will need to coordinate that _extra_
information for prefix length and lists of router addresses.

This whole line of debate seems pointless to me.  You need to support
RS/RA if you're going to operate on any normal IPv6 network.  Why
bother trying to force that data into DHCPv6?  It seems to be a desire
to support a configuration that nobody would need to use.

> I.e., the only way a host is going to be able to use the  
> to send packets for that address to the host in question.

Yes.

> The  

That's right, but it's not required that any DHCPv6 server "owns" all
of the addresses within any given prefix.

> the job and tell the host about the subnet size?

Because we already have a perfectly good protocol to do that -- RAs
already contain that information, so there's no need to duplicate it.

> having DHCPv6 servers tell hosts their addresses breaks exactly this  

I can almost agree with that.

I think a better deployment is to use stateless address assignment
with DHCPv6 Information Request.  That way, the DHCPv6 servers need
not have any address information, and the hosts can forge up addresses
as needed.

Having DHCPv6 servers supply addresses makes some sense to me in an
environment where you have hosts with assigned, fixed addresses, and
you use DHCPv6 to manage central control and renumbering.  It makes
less sense to me in more ad-hoc networks (where, oddly, DHCPv4 is
commonly used).

> a hash based address for shim6 proxy operation)

Yes.

> autoconf) is just as useful but without the potential for trouble

That sounds like IPv4 thinking to me.  If I were an ISP, I'd be
handing out customer prefixes, not addresses.

---

From: James Carlson <[email-masked]>
Date: Tue, 14 Aug 2007 08:43:01 -0400

> It adds up if you have a large number of hosts on a subnet.

I doubt it.  It's something you do just when you're configuring the
interface, and then you're done.

If you're in fact in the state where you can't even bear the load of
configuring the interfaces, then I suspect that neighbor discovery,
DNS, and plain old user data traffic will overwhelm you.  DHCPv6
(using Information Request or Rapid Commit) is just two packets when
the interface is configured.  All those other protocols are going to
add dozens, hundreds, or more for each host.

> a host could serve as both a router solicitation and a DHCP solicit  

I'm not wild about the idea of a single message getting replies from
two separate entities.  I suppose it's doable, but it seems like
needless complexity.  What is being optimized and why?

-- 
James Carlson, Solaris Networking              <[email-masked]>
Sun Microsystems / 1 Network Drive         71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757  From [email-masked] Tue Aug 14 09:28:47 2007
Date: Tue, 14 Aug 2007 08:43:01 -0400
From: James Carlson <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
Cc: Bernie Volz <[email-masked]>
Subject: Re: prefix length determination for DHCPv6

> It adds up if you have a large number of hosts on a subnet.

I doubt it.  It's something you do just when you're configuring the
interface, and then you're done.

If you're in fact in the state where you can't even bear the load of
configuring the interfaces, then I suspect that neighbor discovery,
DNS, and plain old user data traffic will overwhelm you.  DHCPv6
(using Information Request or Rapid Commit) is just two packets when
the interface is configured.  All those other protocols are going to
add dozens, hundreds, or more for each host.

> a host could serve as both a router solicitation and a DHCP solicit  

I'm not wild about the idea of a single message getting replies from
two separate entities.  I suppose it's doable, but it seems like
needless complexity.  What is being optimized and why?

---

From: "David W. Hankins" <[email-masked]>
Date: Mon, 13 Aug 2007 11:10:27 -0500

> with keeping possible misunderstanding or confusing about the base

I agree with everything Jinmei said, but this in particular.  Any
conclusions from these threads have a tendency to get forgotten -
it's better that we argue the position of a draft that an editor
can follow consensus.

But - before I hold my own tongue - I'd like to say that I think Tammy
has given us a kind of horse-sense wisdom that we don't often see at
the IETF;

  http://www1.ietf.org/mail-archive/web/dhcwg/current/msg07421.html

If I may expand on what I took away from that;

- RTADV and DHCPv6 do 'kind of' the same thing.  They configure knobs
  related to the network to which the host is attached.

	From the host's point of view, it is not "on the network"
	until both vehicles succeed.

	To get "on the network" reliably, both vehicles must succeed
	reliably.

	The number of corner cases to manage is staggering.

- It doesn't make a lick of difference to a host which vehicle giv 42.496N   Fax +1 781 442 1677

---

From: "David W. Hankins" <[email-masked]>
Date: Mon, 13 Aug 2007 11:10:27 -0500

- It doesn't make a lick of difference to a host which vehicle gives
  them the configuration information.  Machines can't taste, they
  just consume the config.  Corrolaries;

	A host's user is going to call the systems admin, not the
	router operator, if one, the other, or both vehicles fail.

	Neither will a host's user appreciate the difference between
	configuring its prefix/router and its address/assist-servers.

- It doesn't really appear to make any difference at all to the
  network which vehicle gives them the configuration information.
  Clarifications;

	Ostensibly, the RTADV may be colocated on the router whereas
	DHCPv6 may be remote.

	But just as there's no reason why RTADV can't be colocated
	on a server (such as where there is no router), there is
	also no reason why DHCPv6 can't be colocated on a router
	(such as, in the home, where there is no server).

	So the "fate sharing" principle is bankrupt here: you can
	share whatever fate you want either way.  The existence of
	two separate protocols doesn't create fate.

So one thing we should consider and measure is wether or not this is
an example of "throwing spaghetti at the wall to see what sticks," and
if so wether or not it is worthwhile to make an attempt to clean up.

-- 
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
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "tom.petch" <[email-masked]>
Date: Tue, 14 Aug 2007 12:38:26 +0200

----- Original Message -----
From: "Iljitsch van Beijnum" <[email-masked]>
To: "Bernie Volz ((volz))" <[email-masked]>
Cc: <[email-masked]>; "Alexandru Petrescu" <[email-masked]>;
<[email-masked]>; "John Jason Brzozowski (JJMB)" <[email-masked]>
Sent: Monday, August 13, 2007 8:26 PM
Subject: Re: prefix length determination for DHCPv6

> a host could serve as both a router solicitation and a DHCP solicit

Yes, as long as the router 'server' and the DHCP server get their act together
and present a single coherent reply to the host:-)

Tom Petch

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 15 Aug 2007 00:58:59 +0200

> and present a single coherent reply to the host:-)

If they tell the host the same thing then obviously we don't need two  
protocols.

I don't think there is necessarily a problem with different sources  
telling a host different things. But what we need is some rules about  
how the host is supposed to react to this situation.

Also note that today, this is already reality: you can have multiple  
routers. Hopefully, they all broadcast the same prefixes (if they  
don't, you could use a prefix from router A over router B and run  
into filters, unfortunately, for unexplained reasons, OS makers seem  
to think this is appropriate behavior) but obviously they'll be  
advertising different default gateway addresses. There are no rules  
about which a host should pick, but we do have dead neighbor  
detection which makes sure that only working ones are used.

Back to my original point: a mobile host isn't going to know whether  
a network it connects to is using stateless autoconfig, DHCPv6 or  
both. Sending discovery messages for both is probably wasteful in  
most situations, and sending discovery messages for only one will  
lead to delays if it chose the wrong one. So having one discovery  
message that can lead to replies of both kinds would be useful.  
Additionally, DHCPv6 servers could determine that a host doesn't need  
stateful information and the stateless information is in RAs, so it  
doesn't have to reply to certain request or requests from certain hosts.

---

From: james woodyatt <[email-masked]>
Date: Tue, 14 Aug 2007 16:42:29 -0700

> it's better that we argue the position of a draft that an editor

I agree with M. Jinmei as far as the quoted excerpt above goes.

As much as I dislike DHCPv6 on general principle, I don't expect that  
IETF will abandon it in favor of a system that more coherently  
addresses the various separate concerns that DHCPv6 attempts to  
meet.  I hope the DHC WG will specify requirements for routers  
sending advertisements with the M bit set that prevent any ambiguity  
from arising at the node during link configuration.

p.s. I really wish IETF had deprecated DHCPv6 when it had the  
chance.  Every last thing DHCPv6 does belongs in one of two other,  
separate domains, i.e. either in the sub-IP layer, e.g. EAP, or at  
the sub-application layer, e.g. DNS-SD.  Instead, IETF chose a short- 
sighted and half-baked solution to a problem that really didn't need  
a rush job to solve, and the engineering community today is poorer  
for it.

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 15 Aug 2007 10:19:08 +0900

Iljitsch van Beijnum wrote:

> IPv6 specifications and implementations  without DHCPv6 have been
> around for the better part of a decade,

Given that IPv6 has never really been deployed, we should rather use
OSI, because it has longer history of specification and implementation.

> so  requiring DHCPv6 now
> seems curious at best. In other words: DHCPv6  should be optional.

ARP, DHCPv4, ND and DHCPv6 are all optional.

So?

> If they tell the host the same thing then obviously we don't need two  

That is, we don't need OSI nor IPv6.

Actually, IPv6 without ND is a little better than IPv4 that it may
worth deploying.

							Masataka Ohta

---

From: "Wes Beebee \(wbeebee\)" <[email-masked]>
Date: Wed, 15 Aug 2007 09:29:45 -0400

DHCPv6 is useful when MSO's want to control which CPE's get addresses and which 
do not.  It provides a simple way to do access control on a network.  Could a 
hacked-up rogue system still manage to get on?  Probably - but at least it bars
casual users from getting on a network that they're not supposed to.

- Wes

-----Original Message-----
From: james woodyatt [mailto:[email-masked]] 
Sent: Tuesday, August 14, 2007 7:42 PM
To: IETF IPv6 Mailing List
Cc: [email-masked]
Subject: Re: [dhcwg] RE: prefix length determination for DHCPv6

On Aug 13, 2007, at 09:10, David W. Hankins wrote:
>> now and wait for the document, rather than continue this thread with 
>> keeping possible misunderstanding or confusing about the base 
>> protocol principles.
>
> conclusions from these threads have a tendency to get forgotten - it's 
> better that we argue the position of a draft that an editor can follow 
> consensus.

As much as I dislike DHCPv6 on general principle, I don't expect that IETF will abandon it in favor of a system that more coherently addresses the various separate concerns that DHCPv6 attempts to meet.  I hope the DHC WG will specify requirements for routers sending advertisements with the M bit set that prevent any ambiguity from arising at the node during link configuration.

p.s. I really wish IETF had deprecated DHCPv6 when it had the chance.  Every last thing DHCPv6 does belongs in one of two other, separate domains, i.e. either in the sub-IP layer, e.g. EAP, or at the sub-application layer, e.g. DNS-SD.  Instead, IETF chose a short- sighted and half-baked solution to a problem that really didn't need a rush job to solve, and the engineering community today is poorer for it.

---

From: "David W. Hankins" <[email-masked]>
Date: Tue, 14 Aug 2007 11:34:18 -0700

> know the IP addresses of the operable IPv6 routers on the network.

They effectively do, actually, one way or the other.  The server has
to give out an address that is appropriate for the link to which the
client is attached, and it needs to be able to Confirm the use of
addresses, which it may not have allocated.

So you either:

	- Know all broadcast domains.

	- For each domain, know all prefixes and their lengths.

Or:

	- Have a list of all the 'link-address' fields that all
	  operating DHCPv6 relays will use to identify a link.

	- For each 'link-address', a list of all appropriate addresses
	  for the link (possibly compacted by "contiguous range" or,
	  dare we say, prefix length).

	- A second list, this time of all appropriate addresses that
	  might be allocated by other servers operating on the
	  network.

One of these is easy, the other is rediculously menial.

I think that you will find realistically, DHCPv6 servers will know
prefix lengths.

---

From: "David W. Hankins" <[email-masked]>
Date: Tue, 14 Aug 2007 11:34:18 -0700

So you either:

Or:

> already contain that information, so there's no need to duplicate it.

Surely, there must also be some need to perpetuate two protocols,
other than to simply perpetuate the need not to duplicate their
contents?

> handing out customer prefixes, not addresses.

Even if you delegate a prefix, you still need to know your customer's
address so that you might route packets to them.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 15 Aug 2007 15:13:06 +0200

> > 2. For authentication, authorization and control. I.e., as an ISP, I =
=20
> > want to know which IPv6 belongs to which customer. The interesting =20
> > part here is that it's not necessary for the DHCPv6 server to come up =
=20
> > with the address. What we need is that some central server learns =20
> > about all the addresses. The crucial difference here is that handing =
=20
> > out addresses has the potential for routing problems, while learning =
=20
> > addresses that the host got through other means (probably stateless =20
>=20

--=20
--=20

--zx4FCpZtqtKETZ7O
Content-Type: application/pgp-signature
Content-Disposition: inline

--zx4FCpZtqtKETZ7O--

--===============1819798586==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

--===============1819798586==--

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 15 Aug 2007 15:13:06 +0200

> I think you need to modify the following sentence as such:

> "For better or for worse, the notion of a subnet mask
> **IPv4** is implemented."

No, I was very careful about what I said. The only place that I can  
think of where you don't configure a mask along with an address is in  
the case of HSRP. EVERYWHERE else that I know of you need to specify  
it now that we have CIDR and obviously it was implied before we had  
CIDR. Yes, in IPv6, too.

We can talk long and hard about the pros and cons of this  
architecturally, but the simple truth is that changing this doesn't  
appear to buy as anything tangible and it will require huge amounts  
of work in implementations and then generate huge amounts of  
confusion in operations so PLEASE let's not go down this road.

And if you have to look back before RFC 791 to provide  
counterexamples that really doesn't disprove "ingrained" in my  
opinion...

g>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:[email-masked]?subject=subscribe>
Errors-To: [email-masked]

> I think you need to modify the following sentence as such:

> "For better or for worse, the notion of a subnet mask
> **IPv4** is implemented."

No, I was very careful about what I said. The only place that I can  
think of where you don't configure a mask along with an address is in  
the case of HSRP. EVERYWHERE else that I know of you need to specify  
it now that we have CIDR and obviously it was implied before we had  
CIDR. Yes, in IPv6, too.

We can talk long and hard about the pros and cons of this  
architecturally, but the simple truth is that changing this doesn't  
appear to buy as anything tangible and it will require huge amounts  
of work in implementations and then generate huge amounts of  
confusion in operations so PLEASE let's not go down this road.

And if you have to look back before RFC 791 to provide  
counterexamples that really doesn't disprove "ingrained" in my  
opinion...

---

From: Mark Smith <[email-masked]>
Date: Wed, 15 Aug 2007 19:45:51 +0930

On Mon, 13 Aug 2007 11:55:46 +0200
Iljitsch van Beijnum <[email-masked]> wrote:

<snip>

That being said, it's not quite as ingrained as you might think it is.

The original, pre-classful IPv4 address format was
Network.Node.Node.Node - see RFC760, section 3.1. In addition to
describing IPv4 addresses in this form, IEN115 also describes how a few
different layer 2 addresses can be embedded/converted directly into the
Node.Node.Node octets.

Classes A, B and C where then specified in RFC791, section 3.2.

(ARP could seem to be a "hack" to cope with not being able to squeeze an
ethernet address or any other >3, >2 or >1 octet layer 2 address into
the node portion of class A, B or C format addresses.)

Then subnets came along, and then of course CIDR was introduced.

I think all of this additional addressing complexity was the price to
be paid for scaling IPv4 addressing way beyond what was originally
expected.

Fixed length node addressing is good because it's simpler, easier to
work with, and therefore cheaper to operate. I think anybody who has
worked with Novell IPX (like me) or Appletalk would agree. Both of
those have fixed length node portions.

IPv6, at least for the node portion, is returning to the intentions of
RFC760 era IPv4 without the scaling limitations that were inherent in
IPv4's 32 bit address space.

A fixed length network portion is also simpler and easier to administer
and operate if you have the opportunity, which is why I'm an advocate
for /48s for nearly everybody. Leaving the problems of dealing with the
complexity of variable length prefixes to the expert employees of the
network service providers, not their customers, makes good sense to me.
Again, I think people who've worked with Novell IPX or Appletalk would
also agree.

Regards,
Mark.

---

From: <[email-masked]>
Date: Wed, 15 Aug 2007 15:00:24 +0100

> A fixed length network portion is also simpler and easier to 
> administer and operate if you have the opportunity, which is 
> why I'm an advocate for /48s for nearly everybody. Leaving 
> the problems of dealing with the complexity of variable 
> length prefixes to the expert employees of the network 
> service providers, not their customers, makes good sense to me.
> Again, I think people who've worked with Novell IPX or 
> Appletalk would also agree.

Then you need to get involved in setting RIR policy because this concept
of the fixed /48 network size is already starting to disappear. Nobody
from the IETF was available to explain why the designers of IPv6
intended for /48 to be the fixed length network size when ARIN passed a
policy to allow ISPs to allocate /56s to consumer customers. Even though
the ARIN decision was not a bad one, unless better understanding of the
IPv6 design is communicated, then the /48 boundary will fade away and
everyone will have to renumber their networks when they change
providers.

--Michael Dillon

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 15 Aug 2007 16:18:54 +0200

On 15-aug-2007, at 16:00, <[email-masked]>  
<[email-masked]> wrote:

> Nobody from the IETF was available to explain why the designers of  
> IPv6
> the ARIN decision was not a bad one,

I'm still somewhat blue in the face from explaining exactly why this  
was a bad decision.

- extremely few people need more than a /48
- /48 everywhere means that you don't have to renumber bits 48 - 63  
when you change ISPs
- a decent number of people need more than a /56
- of that number, many won't know it in advance
- with 256 subnets deployed you're already big enough that  
renumbering is painful

The right choice is to give a /48 to people who want one and a /60 to  
everyone else. If you discover that you need more than a /60 and you  
only have upto 16 subnets deployed renumbering is much easier than  
with /56 and 256. With /56 you need to think about it in advance,  
which we want to avoid because thinking hurts and usually, the  
results are wrong.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 16 Aug 2007 00:33:20 +1000

> > A fixed length network portion is also simpler and easier to=20
> > administer and operate if you have the opportunity, which is=20
> > why I'm an advocate for /48s for nearly everybody. Leaving=20
> > the problems of dealing with the complexity of variable=20
> > length prefixes to the expert employees of the network=20
> > Again, I think people who've worked with Novell IPX or=20

	While end sites are expected to be given a /48, that was
	expected to be divided into 65536 subnets of /64.  Whether
	you used all the 65536 subnets didn't matter.  It was enough
	subnets to cover all but the very large enterpises.

	Even if you needed more it should not be a real issue for
	ISP's to supply you with a /47 to give you 131072 subnets.
	Moving ISPs should still be easy as you are only equivalent
	to two customers.

	I suspect with /56 there will end up being a reasonable
	number of exception customers.  Enough I suspect that ISP's
	will maintain two pools.  One for /56's and one for /48's.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: James Carlson <[email-masked]>
Date: Wed, 15 Aug 2007 10:33:16 -0400

David W. Hankins writes:
> client is attached,

If the DHCPv6 assigns addresses at all (as opposed to just providing
configuration parameters), then it needs to be able to work within the
prefixes assigned on the link.  That's true.  It needn't use *all* of
the addresses possible within the prefix, and that's the configuration
management part.

> and it needs to be able to Confirm the use of

That doesn't make sense to me.  The DHCPv6 Confirm message is for
confirming an address lease.  If the server hasn't allocated the
lease, then it _cannot_ confirm anything about the address and must
Nak in response.  If it does confirm addresses it hasn't allocated,
then it's just broken.

> 	  operating DHCPv6 relays will use to identify a link.

I'm confused.  Why would relays be confirming anything?

> I think that you will find realistically, DHCPv6 servers will know

None that I've worked with (including the WIDE server) seems to care.
What's needed are assignment ranges, not prefixes.

> other than to simply perpetuate the need not to duplicate their

If you're going to deprecate DHCPv6 for address assignment and fold it
into the RA mechanism, then I'd be (somewhat weakly) in favor of that.

If you're just going to duplicate things, then I'm very much opposed.

> address so that you might route packets to them.

I don't understand that.

If you delegate a prefix, then you route to the prefix -- best match.
Why would you care about individual addresses within the prefix?

---

From: james woodyatt <[email-masked]>
Date: Wed, 15 Aug 2007 10:14:26 -0700

On Aug 15, 2007, at 06:29, Wes Beebee (wbeebee) wrote:
>
> DHCPv6 is useful when MSO's want to control which CPE's get  
> addresses and which do not.  It provides a simple way to do access  
> control on a network.

EAP is a better way to do that.  DHCPv6 is more useful for  
controlling which CPE gets what addresses from a centrally  
administered network service.  I just don't see how that solves any  
*real* problems; that's all.  Why should it matter what address each  
CPE interface is assigned, as long as it's reachable, authenticated,  
authorized and accounted?  (Answer: because there are lazy people  
using interface addresses as CPE device identifiers in security  
protocols, when there are perfectly good alternatives in IPv6 that  
have the added virtue of actually functioning properly.)

As near as I can tell, the one architecturally goodish thing DHCPv6  
has going for it is prefix delegation.  There's no way to do that  
with straight router advertisements-- more's the pity.  (Once again,  
IETF stopped short of redesigning the full Appletalk protocol stack,  
which supported ad-hoc routed internets, sort of... but, alas, I'm  
beginning to degenerate.)

> Could a hacked-up rogue system still manage to get on?  Probably -  
> but at least it bars casual users from getting on a network that  
> they're not supposed to.

Probably?  Try: absolutely.

I could tell you how I used a commercial off-the-shelf product at  
IETF 69 to bypass the hotel's stupid method of using DHCP to prevent  
me from interposing my Wi-Fi NAT gateway into the in-room Internet  
service.  It's a supported feature of the product I used, expressly  
marketed to customers for the purpose of making it easy for casual  
users to do this. If they had used an appropriate technology, it  
wouldn't have mattered whether I was using a bridge or a router or I  
was directly connected, and they would have still been assured that  
only my one computer was permitted to access their network.  Instead,  
they were relying on my good will not to run an open Wi-Fi AP and  
allow everybody in the rooms around me to share my access.

Operators who depend on DHCPv6 alone to deter users from accessing  
their networks with unauthorized devices are just going to end up  
peeving their paying customers with needless interoperability  
complexity.  Some operators have already discovered this, and they've  
now stopped using DHCP as an access control mechanism.

---

From: Ole Troan <[email-masked]>
Date: Wed, 15 Aug 2007 19:05:51 +0100

> Yes, but how does that route get in the table, and what next-hop is
> set?  You have to know your customer's address eventually.

next-hop is the link-local address though.

/ot

---

From: James Carlson <[email-masked]>
Date: Wed, 15 Aug 2007 14:16:31 -0400

> next-hop is the link-local address though.

Right; it's the link-local address of the router to which you've
delegated the prefix.

It's not the address of every single machine on the customer's
network.  In fact, knowing the addresses of the machines on the
customer's network is useless, as it doesn't tell you the address of
that CPE router.

Obvious sorts of ways to get this would be to keep track of your
delegations or (alternatively) use an appropriate routing protocol.

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 16 Aug 2007 17:55:39 +0900

At Wed, 15 Aug 2007 10:51:40 -0700,
"David W. Hankins" <[email-masked]> wrote:

> I'm familiar with half of the story here, and uncomfortable with
> speaking about a specific competitor's product (but it appears I will
> do it anyway).  My opinion of WIDE's Confirm message processing is
> that it does know the prefix length: it assumes all prefixes are /64,
> by comparing the first 8 bytes of addresses.
> 
> I make no judgement here of the efficacy or correctness of this
> implementation.
> 
> If there is an expert on WIDE's implementation that can describe how
> it reaches a dynamic pool from relays (without relays, it appears to
> follow interface definitions), I'm curious to know the rest of the
> story.

I'm not an "expert" on the WIDE implementation (any more), but I know
the implementation well enough that I can clarify the points, so...

Your understanding about the Confirm message processing of the WIDE
server is correct.  (And I don't think this way of handling Confirm is
really an appropriate behavior).

The WIDE server implementation doesn't care about the link prefix when
assigning an address from a pool.  This is also not an appropriate
behavior because it could assign an address that is not valid for the
link to which the client is attached.

So, I think you're right in that realistically the DHCPv6 server
operator needs to understand the link prefixes of the addresses
assigned via DHCPv6.  This also means the DHCPv6 server will
realistically be able to provide this information for the clients.
(The server might still work properly just based on the knowledge
about its own local links and on the content of 'link address'
information of relayed messages.  But such an operation does not seem
"realistic" to me).

But I don't think this immediately justifies the introduction of
an on-link prefix option to DHCPv6.  To rely on this feature, the
DHCPv6 operator would need to know all on-link prefixes including ones
that are not used for DHCP-based address assignment, and would need to
configure them on the server.  Although the additional overhead is
minor, it can still be an unnecessary operational cost and can cause
configuration inconsistency that could actually avoided.  On the other
hand, routers should inherently know the on-link prefix information to
route packets appropriately, so providing this information via RA
still looks better than the DHCP-based approach.

IMO, this discussion is going to miss the point.  The problem is not
whether we can provide on-link prefix information via DHCPv6 (yes we
can) or whether it's reasonable per se (it might), but whether we
should do this while RA already has this provision and would actually
be better than DHCPv6-based approach.  A new draft from the dhc group
will reportedly (hopefully?) answer this main question, so, again, I
think we should hold off for a while.

					JINMEI, Tatuya

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 16 Aug 2007 00:08:13 +0200

On 15-aug-2007, at 23:48, Mark Smith wrote:

> I'm don't think I'm going down it. You seemed to be questioning why
> subnets were fixed length,

How are subnets fixed in size??

The discussion we were having was whether DHCPv6 in particular or any  
mechanism in general should distribute a subnet size in the form of a  
prefix length along with IP addresses. This discussion is only  
relevant when the size isn't fixed.

Although there is that infamous line about 64-bit interface  
identifiers for everything except ::/3 in RFC 3513 (the origin of  
which nobody has been able to explain so far despite my repeated  
requests), IPv6 has always been classless with no assumptions about  
the structure of addresses.

> I think that shows that when there is the opportunity to
> have fixed length node addressing it is very desirable, and has been
> chosen by many protocol designers (DECNET Phase IV has it too, IIRC)

Note though that all these protocols were designed for networks with  
a limited scope, unlike IP which was more or less designed and then  
became the protocol for all devices in the whole world.

The problem with a fixed length is that it's always either too large  
or too small. So when we get around to designing the successor of  
IPv6, we really need to use variable length addresses for that.

> I like that IPv6 can place the boundary between the network and node
> portion anywhere within the address, unlike IPX and Appletalk. It
> future proofs the protocol, ensuring that should the network or node
> portions not be big enough they can be changed

Right. It means that whatever we do, we'll never run out of IPvFrom [email-masked] Thu Aug 16 05:13:36 2007
From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 16 Aug 2007 00:08:13 +0200
To: Mark Smith <[email-masked]>
Cc: "volz <[email-masked]>, [email-masked], [email-masked],
	\"John Jason Brzozowski \(JJMB\)\" <[email-masked]>" <Bernie>
Subject: Re: prefix length determination for DHCPv6

On 15-aug-2007, at 23:48, Mark Smith wrote:

> I'm don't think I'm going down it. You seemed to be questioning why
> subnets were fixed length,

How are subnets fixed in size??

The discussion we were having was whether DHCPv6 in particular or any  
mechanism in general should distribute a subnet size in the form of a  
prefix length along with IP addresses. This discussion is only  
relevant when the size isn't fixed.

Although there is that infamous line about 64-bit interface  
identifiers for everything except ::/3 in RFC 3513 (the origin of  
which nobody has been able to explain so far despite my repeated  
requests), IPv6 has always been classless with no assumptions about  
the structure of addresses.

> I think that shows that when there is the opportunity to
> have fixed length node addressing it is very desirable, and has been
> chosen by many protocol designers (DECNET Phase IV has it too, IIRC)

Note though that all these protocols were designed for networks with  
a limited scope, unlike IP which was more or less designed and then  
became the protocol for all devices in the whole world.

The problem with a fixed length is that it's always either too large  
or too small. So when we get around to designing the successor of  
IPv6, we really need to use variable length addresses for that.

> I like that IPv6 can place the boundary between the network and node
> portion anywhere within the address, unlike IPX and Appletalk. It
> future proofs the protocol, ensuring that should the network or node
> portions not be big enough they can be changed

Right. It means that whatever we do, we'll never run out of IPv6  
address space because if needed, we could run the entire network on a  
single /64. That's still 32 more bits than IPv4 has.

> OTOH, I don't like _unnecessary_ complexity. Currently,
> we don't need to engage any of the complexity of non-fixed network and
> node portion boundaries in IPv6, so let's not until we need to.
> Allowing for something doesn't mean you must use it.

"Use it or lose it." If you run a network with a defacto boundary at / 
64 for a decade, don't be surprised when you can't move that boundary  
without breaking stuff.

---

From: Mark Smith <[email-masked]>
Date: Thu, 16 Aug 2007 07:18:47 +0930

On Wed, 15 Aug 2007 15:13:06 +0200

> think of where you don't configure a mask along with an address is in  
6

---

From: Mark Smith <[email-masked]>
Date: Thu, 16 Aug 2007 07:18:47 +0930

I'm don't think I'm going down it. You seemed to be questioning why
subnets were fixed length, I provided most likelyreasons why, including
evidence that the original design of IPv4, pre-classes, also followed
this model. I think that shows that when there is the opportunity to
have fixed length node addressing it is very desirable, and has been
chosen by many protocol designers (DECNET Phase IV has it too, IIRC)

I like that IPv6 can place the boundary between the network and node
portion anywhere within the address, unlike IPX and Appletalk. It
future proofs the protocol, ensuring that should the network or node
portions not be big enough they can be changed, and devices will be
able to cope with it without software upgrades.

Simplicity is what we get when we eliminate/avoid/choose not to use
variable length subnets, and it is a very tangible property, well worth
pursuing. I could probably save 5 minutes per day at work if I didn't
having to think through or calculate variable length subnet masks in
IPv4. That's 1200 minutes or 20 hours a year. Multiply that by how many
operators there are out there spending that 5 minutes or more per day
and it's a huge amount of spent time. That's a necessary expense when
dealing with IPv4, but not a necessary one for IPv6. If it's not
necessary, then it's wasted time.

> counterexamples that really doesn't disprove "ingrained" in my  

That's probably a fair critism. I was mainly replying to what I've
realised was an earlier question of yours, regarding why fixed length
subnets. The ingrained bit seemed to me to suggesting that fixed length
subnets would be considered to be a radical idea and wouldn't be
acceptable to those that have led sheltered protocol lives and only
ever dealt with IPv4, post 1995.

Regards,
Mark.

I'm don't think I'm going down it. You seemed to be questioning why
subnets were fixed length, I provided most likelyreasons why, including
evidence that the original design of IPv4, pre-classes, also followed
this model. I think that shows that when there is the opportunity to
have fixed length node addressing it is very desirable, and has been
chosen by many protocol designers (DECNET Phase IV has it too, IIRC)

I like that IPv6 can place the boundary between the network and node
portion anywhere within the address, unlike IPX and Appletalk. It
future proofs the protocol, ensuring that should the network or node
portions not be big enough they can be changed, and devices will be
able to cope with it without software upgrades.

Simplicity is what we get when we eliminate/avoid/choose not to use
variable length subnets, and it is a very tangible property, well worth
pursuing. I could probably save 5 minutes per day at work if I didn't
having to think through or calculate variable length subnet masks in
IPv4. That's 1200 minutes or 20 hours a year. Multiply that by how many
operators there are out there spending that 5 minutes or more per day
and it's a huge amount of spent time. That's a necessary expense when
dealing with IPv4, but not a necessary one for IPv6. If it's not
necessary, then it's wasted time.

> counterexamples that really doesn't disprove "ingrained" in my  

That's probably a fair critism. I was mainly replying to what I've
realised was an earlier question of yours, regarding why fixed length
subnets. The ingrained bit seemed to me to suggesting that fixed length
subnets would be considered to be a radical idea and wouldn't be
acceptable to those that have led sheltered protocol lives and only
ever dealt with IPv4, post 1995.

Regards,
Mark.

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 15 Aug 2007 10:51:40 -0700

> Nak in response.  If it does confirm addresses it hasn't allocated,

I'm not sure where you got that idea - certainly not from RFC3315
section 18.2.2 ("Receipt of Confirm Messages" under "Server
Behavior").

I'll spare pasting the content to the lists - please have a read
and let me know if you still disagree.

> I'm confused.  Why would relays be confirming anything?

I'm sorry - this is a DHCPv6 protocol mechanic, something only
a DHCP geek would know.

The relay messages' 'link-address' field is central to the server's
calculation of the client's location (which "broadcast domain"
they're attached to).

Basically it's how you know which addresses are appropriate for the
client, based on what network they're attached to.

So this is a server inspecting a chain of relayed messages and
finding the link-address(es) it thinks are relevant to the client.
Then using that as a key to find the address(es) it needs to
deliver to the client.

One way to do this is to find a prefix that contains the selected
link-address (masking and comparing) and work outwards.

One other way to do this is to index the link-addresses specifically,
or some approximation of the same.

Does that make more sense now?

> If you're just going to duplicate things, then I'm very much opposed.

Neither of those really sound like a good idea to me, but then I'm
also lacking the power to do either of them.  I guess the grass is
not always greener on the other side.

But let's save this discussion for a draft.  Rumor has it, someone is
writing one on this topic (or at least exploring the issues), and I
want to read what they have to say.

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 15 Aug 2007 12:01:58 -0700

> Right; it's the link-local address of the router to which you've

Well, sometimes.  It depends what you're doing.

Either way:  You need to know the customer's address.  A DHCPv6 server
off in the weeds does not necessarily know what link local address the
client is using (because it might change without notification).  It
may know what global addresses the client is using (because it
allocated them), but won't if router solicition is in use.  A
router solicitation system certainly doesn't have any knowledge of
which customer is which nor what addresses global or not which they're
using.

This is but one facet of a network's operation: try not to focus on
it too much.  There are potentially a multitude of reasons to know
which of your customers are online, and how to reach them.  Testing
connectivity alone (such as during a support call).

> customer's network is useless, as it doesn't tell you the address of

I'm not sure why you make this declaration (twice now), when no one
has suggested the counterpositive.  Maybe I misunderstood Iljitsch.

> delegations or (alternatively) use an appropriate routing protocol.

Which I think gets us back to what Iljitsch said in the first place,
except that realistically ISPs are going to find it difficult and/or
costly to trust routing information from eg broadband customers, so
really what you're looking at is some way to provide a register of
your customers' current addresses.

---

From: Ignatios Souvatzis <[email-masked]>
Date: Thu, 16 Aug 2007 12:46:29 +0200

> chosen by many protocol designers (DECNET Phase IV has it too, IIRC)

Historical remark: To a certain degree.

Area addresses have a fixed size (6 bits), and node addresses within an
area also have a fixed size (10 bits). But Areas are not bound to a
LAN. All host addressing on a link is done via sort of neighbour
discovery (using hello packets). Areas are used for (I think) IS-IS- or
OSPF-like two-level routing, but could consist of any number of LANs
and point to point links.

(Ethernet LAN addresses were created by concatenating the full DECnet
address (16 bits) and DEC's prefix AA-00-04-00-.)

	-is

---

From: James Carlson <[email-masked]>
Date: Thu, 16 Aug 2007 08:53:10 -0400

> section 18.2.2 ("Receipt of Confirm Messages" under "Server

I don't see how the server could possibly construct a valid Reply
message otherwise.  It needs to include IA Address options, and those
need to have preferred-lifetime and valid-lifetime.

I'd agree that the language seems incomplete.

> I'm sorry - this is a DHCPv6 protocol mechanic, something only

You're pardoned.  I've only implemented one commercially-shipping
and deployed DHCPv6 client implementation.  ;-}

> calculation of the client's location (which "broadcast domain"

The link-address is:

      link-address   A global or site-local address that will be used by
                     the server to identify the link on which the client
                     is located.

I expect that to be the relay's global IPv6 address on the link on
which the client is located, if there is such an address.

> client, based on what network they're attached to.

It's how you (as a relay) know where the client is located so that you
can reach it again when the server sends back the responses.

The server itself _can_ use link-address to determine where in the
world the client is located, but that doesn't mean that the relay is
doing this validation (which is what I had thought you were saying),
and it also doesn't mean that the client itself is on the same prefix.

Note that link-address can be 0, if the relay doesn't have a global
address on that interface, and the server will have to choose a
different means to get the information it needs.  So, it's not an
absolute identifier of the prefix.

Yes.

> set?  You have to know your customer's address eventually.

If there's a delegated prefix, I'd _assume_ that there's a router in
the way.  Otherwise, delegating a prefix is a little strange.

If there's a router in the way, then it's the router's link-local
address that you need, not the customers end-node assigned addresses.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 16 Aug 2007 15:35:57 -0400

I personally think all this discussion is much ado about nothing. It's
incorrect thinking to deploy an IPv6 router without RA. RA supports all
of prefix information and on-link determination, so why have DHCPv6
duplicate that functionality? Bernie already mentioned why it's
dangerous if two entities in DHCPv6 server and IPv6 router issue
duplicate information one of which could be different. I also feel
DHCPv6 WG should not take up any work item to start working on
supporting any new option that duplicates PIO of RA nor work on a
default router option. As many folks have said, please don't think IPv6
like IPv4. Also, aside of SLAAC where a default prefix length can be
assumed but cannot be used for on-link determination, no other IPv6
deployment make sense to assume any default prefix length. This is the
new property of an IPv6 network for the router to be able to assign any
prefix length to nodes the router serves.

The other discussion about routers in broadband residential homes etc.,
can be a separate discussion held in dhcpwg. IPv6 data WG has other
important problems to consider like something as basic as a host data
forwarding is broken due to misconceptions about on- vs. off-link
determination.

Hemant

-----Original Message-----
From: JINMEI Tatuya / ???? [mailto:[email-masked]] 
Sent: Thursday, August 16, 2007 4:56 AM
To: David W. Hankins
Cc: [email-masked]; [email-masked]
Subject: Re: [dhcwg] Re: prefix length determination for DHCPv6

So, I think you're right in that realistically the DHCPv6 server
operator needs to understand the link prefixes of the addresses assigned
via DHCPv6.  This also means the DHCPv6 server will realistically be
able to provide this information for the clients.
(The server might still work properly just based on the knowledge about
its own local links and on the content of 'link address'
information of relayed messages.  But such an operation does not seem
"realistic" to me).

But I don't think this immediately justifies the introduction of an
on-link prefix option to DHCPv6.  To rely on this feature, the
DHCPv6 operator would need to know all on-link prefixes including ones
that are not used for DHCP-based address assignment, and would need to
configure them on the server.  Although the additional overhead is
minor, it can still be an unnecessary operational cost and can cause
configuration inconsistency that could actually avoided.  On the other
hand, routers should inherently know the on-link prefix information to
route packets appropriately, so providing this information via RA still
looks better than the DHCP-based approach.

IMO, this discussion is going to miss the point.  The problem is not
whether we can provide on-link prefix information via DHCPv6 (yes we
can) or whether it's reasonable per se (it might), but whether we should
do this while RA already has this provision and would actually be better
than DHCPv6-based approach.  A new draft from the dhc group will
reportedly (hopefully?) answer this main question, so, again, I think we
should hold off for a while.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba
Corp.
					[email-masked]

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 16 Aug 2007 16:52:33 -0400

client is 
>using (because it might change without notification). 

If the client performed DHCPv6 with server, and the deployment includes
a relay agent between client and server, then the peer-address between
relay and server lets the server know what is the link-local address of
the client. Also each time the link-local address of the client changes
for a DHCPv6 client, the client will reinitiate DHCPv6 which lets the
server know again what the latest link-local address is.

If you are talking about a more generalized DHCPv6 deployment, then show
us a topology and we can discuss it.

As for broadband operators and untrusted devices in residential homes,
one plan for IPv6 cable MSO's is to dole out a PD to an eRouter cable
modem. The PD is doled out by DHCPv6 server. DHCPv6 Lease Query protocol
can verify the cable modem eRouter traffic by sending a query by address
from relay to server. 
A query by address will return the client information for either that
client that has been assigned that address *OR* been delegated a prefix
that contains that address. See the URL below for details on DHCPv6
Lease Query protocol.

http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-leasequery-01.
txt

Hemant

-----Original Message-----
From: David W. Hankins [mailto:[email-masked]] 
Sent: Wednesday, August 15, 2007 3:02 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [dhcwg] Re: prefix length determination for DHCPv6

On Wed, Aug 15, 2007 at 02:16:31PM -0400, James Carlson wrote:
> > > Yes, but how does that route get in the table, and what next-hop 
> > > is set?  You have to know your customer's address eventually.
> > 

Either way:  You need to know the customer's address.  A DHCPv6 server
off in the weeds does not necessarily know what link local address the
client is using (because it might change without notification).  It may
know what global addresses the client is using (because it allocated
them), but won't if router solicition is in use.  A router solicitation
system certainly doesn't have any knowledge of which customer is which
nor what addresses global or not which they're using.

This is but one facet of a network's operation: try not to focus on it
too much.  There are potentially a multitude of reasons to know which of
your customers are online, and how to reach them.  Testing connectivity
alone (such as during a support call).

> customer's network is useless, as it doesn't tell you the address of 

I'm not sure why you make this declaration (twice now), when no one has
suggested the counterpositive.  Maybe I misunderstood Iljitsch.

Which I think gets us back to what Iljitsch said in the first place,
except that realistically ISPs are going to find it difficult and/or
costly to trust routing information from eg broadband customers, so
really what you're looking at is some way to provide a register of your
customers' current addresses.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 16 Aug 2007 16:59:21 -0400

Wrt:

>I'm sorry - this is a DHCPv6 protocol mechanic, something only a DHCP
geek would know.

David is correct about use of Link-addr by server above. Link-addr is
the equivalent of giaddr in DHCPv4. 

Hemant

-----Original Message-----
From: David W. Hankins [mailto:[email-masked]] 
Sent: Wednesday, August 15, 2007 1:52 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [dhcwg] Re: prefix length determination for DHCPv6

On Wed, Aug 15, 2007 at 10:33:16AM -0400, James Carlson wrote:
> > and it needs to be able to Confirm the use of addresses, which it 
> > may not have allocated.
> 

I'm not sure where you got that idea - certainly not from RFC3315
section 18.2.2 ("Receipt of Confirm Messages" under "Server Behavior").

I'll spare pasting the content to the lists - please have a read and let
me know if you still disagree.

> I'm confused.  Why would relays be confirming anything?

I'm sorry - this is a DHCPv6 protocol mechanic, something only a DHCP
geek would know.

So this is a server inspecting a chain of relayed messages and finding
the link-address(es) it thinks are relevant to the client.
Then using that as a key to find the address(es) it needs to deliver to
the client.

One other way to do this is to index the link-addresses specifically, or
some approximation of the same.

I'm familiar with half of the story here, and uncomfortable with
speaking about a specific competitor's product (but it appears I will do
it anyway).  My opinion of WIDE's Confirm message processing is that it
does know the prefix length: it assumes all prefixes are /64, by
comparing the first 8 bytes of addresses.

If there is an expert on WIDE's implementation that can describe how it
reaches a dynamic pool from relays (without relays, it appears to follow
interface definitions), I'm curious to know the rest of the story.

> If you're just going to duplicate things, then I'm very much opposed.

Neither of those really sound like a good idea to me, but then I'm also
lacking the power to do either of them.  I guess the grass is not always
greener on the other side.

But let's save this discussion for a draft.  Rumor has it, someone is
writing one on this topic (or at least exploring the issues), and I want
to read what they have to say.

> > Even if you delegate a prefix, you still need to know your 
> > customer's address so that you might route packets to them.
> 
> I don't understand that.
> 

Yes, but how does that route get in the table, and what next-hop is set?
You have to know your customer's address eventually.

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 16 Aug 2007 11:12:31 -0700

> message otherwise.  It needs to include IA Address options, and those

The server does not include IA_*'s nor IAADDRs beneath them.  It
only MUST include a server-identifier option, and a status code
option (although there's no normative text) specifying the status of
the Confirm operation.  18.2.2 again.

> need to have preferred-lifetime and valid-lifetime.

The client MUST include the IA_*'s, and any IAADDRs within them, with
the t1, t2, preferred and valid lifetimes all set to zero.  The
server MUST ignore these fields.  18.1.2 plus 18.2.2.

This is one of the unfortunate successes of DHCPv6.  RFC3315's
format is to create a section for the specific behaviours and
requirements for each message by message type, and to have states
clearly delineated with separate messages.  Compared to DHCPv4,
which only had 4 messages for 8 or so purposes and so required that
you keep track of a state engine while you read, this was a major
improvement.

But since 'Reply' is used to reply to multiple messages, and there are
fewer sections to cover it, this gives the text a very unusual
quality...it goes from very easy to very hard with no warning.

It's quite difficult to make heads or tails of what's goig on after
you finish with the Reply message sections.

> doing this validation (which is what I had thought you were saying),

Yes, that's where we're not communicating - in the piece of text you
were replying to, I was describing a server behaviour based upon
information supplied by relay agents.

A relay is just a relay.

> absolute identifier of the prefix.

I think this is something we talked about at the DHCPv6 bakeoff
possibly needing some clarification.  That's another draft I
anticipate reading.

Basically, absent of some "special guidance from the admin", the
anticipation is that you start from the 'clientmost' end of the
relay-forward chain, and move 'servermost' iteratively until
you find a nonzero value (this can be done in reverse while
seeking down the chain to the client's packet to process it).

If you do find a nonzero value, you use that to find the broadcast
domain (and then valid addresses somehow).

If you do not find a nonzero value, then the client is located on
the same broadcast domain as the interface upon which the server
received the packet, and you give addresses valid for that domain.

In either case if the operator has told you what you should do, you
should just do that.

The link-address field is absolutely the identifier of the broadcast
domain, which corresponds therefore to one or more prefixes.  The
administrator's will as expressed in configuration syntax is an
ultimate identifier.

I think what we decided (and what seemed to be the Prague consensus)
was that this could use some clarification.

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 16 Aug 2007 11:52:42 -0700

> really an appropriate behavior).

I think the authors also placed a "XXX" comment on the relevant
sources, so there appears to be some agreement with you there.

But it's not like I'm not guilty of the same thing sometimes.

> link to which the client is attached.

Thank you Jinmei, my curiosity is sated.

So my understanding is that it chooses addresses to allocate based
upon which interface it received the message on.

> IMO, this discussion is going to miss the point.

My intent is to clear up what I perceive to be technical errors
(others' or my own), not to argue the main points.

If there's some overlap, real or perceived, that is my error.

Why settle for the lesser evil?	 https://secure.isc.org/store/t-shirt/

---

From: "TJ" <[email-masked]>
Date: Thu, 16 Aug 2007 18:26:16 -0400

WRT "IPv6 design is communicated, then the /48 boundary will fade away and
everyone will have to renumber their networks when they change providers."
	... technically, they will need to renumber anyway - but now they
will also need to re-architect their network / subnet allocation.

AFAIK, the move towards /56 allocations is simply a nod towards address
conservation / efficient allocation policies.
	For my $.02 - I would hope that any client moving from one ISP's /48
would "encourage" the new ISP to match the allocation size :).
		((Or, go PI at that time ... get their own allocation ...
and not worry about it every again.))

/TJ

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, August 15, 2007 10:00 AM
To: [email-masked]; [email-masked]
Subject: RE: prefix length determination for DHCPv6

--Michael Dillon

---

From: "TJ" <[email-masked]>
Date: Thu, 16 Aug 2007 18:29:35 -0400

" 	I suspect with /56 there will end up being a reasonable
	number of exception customers.  Enough I suspect that ISP's
	will maintain two pools.  One for /56's and one for /48's "

... which means now the customer who got a /56 needs to renumber in order to
move to the /48 :(.  
	Not necessary if the ISP in question followed a more flexible
allocation method (a la RFC3531).

/TJ

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 17 Aug 2007 00:41:55 +0200

On 16-aug-2007, at 21:35, Hemant Singh (shemant) wrote:

> RA supports all
> duplicate that functionality?

That's not the discussion we were having. The discussion we were  
having (or at least, _I_ was having) was whether it's a good idea to  
have a prefix LENGTH go along with the IPv6 address if a DHCPv6  
server assigns an IPv6 address to a host.

In my opinion, the answer is "of course" because otherwise life gets  
quite complex, but apparently there are people who like that kind of  
thing and who feel that an address with an unknown prefix length is  
useful.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 16 Aug 2007 18:51:29 -0400

OK, Iljitsch. But hasn't Bernie already responded to this one? What if
prefix length is fat-fingered at the DHCPv6 server by the admin and a
length L1 is sent in DHCPv6 messages but the router RA sent a PIO for
the same prefix with prefix length L2. So as Bernie says, who wins? What
does the host now do?

Further, isn't sending prefix length in DHCPv6 messages duplicating what
RA PIO prefix length field already is capable of doing?

Lastly, what huge problem is sending prefix length in DHCPv6 messages
going to solve that is not solved by ND RA, RA PIO, and existing DHCPv6?

Hemant

-----Original Message-----
From: Iljitsch van Beijnum [mailto:[email-masked]] 
Sent: Thursday, August 16, 2007 6:42 PM
To: Hemant Singh (shemant)
Cc: JINMEI Tatuya / ????; David W. Hankins; [email-masked];
[email-masked]

> duplicate that functionality?

That's not the discussion we were having. The discussion we were having
(or at least, _I_ was having) was whether it's a good idea to have a
prefix LENGTH go along with the IPv6 address if a DHCPv6 server assigns
an IPv6 address to a host.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 17 Aug 2007 01:07:35 +0200

> the same prefix with prefix length L2. So as Bernie says, who wins?  

(Can't seem to remember what PIO stands for...)

What if someone misconfigures the dot zone file and the entire DNS  
goes down?

Mistakes happen. There is no cure for stupidity. Etc, and so on, ad  
nauseum.

The problem that I have is that if an address without a prefix length  
becomes available, what do I do? Then I need to do different things  
depending on what other information is available and redo all of this  
when new information becomes available. It's a mess.

If a DHCPv6 server tells me I have address 2003::2003/68 and then I  
get a router advertisement with a prefix option for 2003::/60 then I  
know that both 2003::/68 and 2003::/60 are directly connected to my  
interface. That the two happen to overlap is somewhat curious, but  
otherwise no big deal.

I.e., in practice, the shortest prefix "wins".

> RA PIO prefix length field already is capable of doing?

Since when is there a requirement that a piece of information may not  
be learned through two ways independently?

The point is that if a DHCPv6 server gives out addresses without a  
prefix lenght, it only does half a job. Sure, you can let another  
protocol pick up the slack and in theory that may not seem like a  
problem, but the trouble is that in practice, different protocols run  
and possibly fail at different times so the permutations increase  
rapidly while if you just put it in the DHCPv6 message and get it  
over with, life is simple and we can all go home early.

> going to solve that is not solved by ND RA, RA PIO, and existing  

Not a thing until someone is going to start USING DHCPv6 address  
assignment, I'd say.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 16 Aug 2007 19:38:29 -0400

PIO is Prefix Information Option of RA. Let me reply to your comments
one by one.

Grossly speaking, I disagree with you on most counts.

>The problem that I have is that if an address without a prefix length
becomes available, what do I do?
 
How can that happen with a DHCPv6 host? RA will always precede DHCPv6
transactions because unless the host sees an RA with M bit set the host
will not initiate DHCPv6. Such a RA can include a prefix and prefix
length in PIO. If RA doesn't include any PIO, then the host still
initiates DHCPv6, completes DHCPv6 and then sends all non-link-local
traffic to the default router and wait for any Redirects.

>Sure, you can let another protocol pick up the slack and in theory that
may not seem like a problem, but the trouble is that in practice,
different 
>protocols run and possibly fail at different times so the permutations
increase rapidly while if you just put it in the DHCPv6 message and get
it over 
>with, life is simple and we can all go home early.

All generic talk. Let's say if RA fails, then the host will never get a
signal to initiate DHCPv6. What random failures are you talking about. I
am not buying any random failures and any permutations just yet.

assignment, I'd say.

OK, I deployed DHCPv6 address assignment today. Start listing show
stopper problems to me. If you feel so strongly about it, put the show
stopper problems in an Internet-Draft document so we have all the issues
captured and not have to sift thru zillion emails that could go off to a
tangent. 

Hemant

-----Original Message-----
From: Iljitsch van Beijnum [mailto:[email-masked]] 
Sent: Thursday, August 16, 2007 7:08 PM
To: Hemant Singh (shemant)
Cc: JINMEI Tatuya / ????; David W. Hankins; [email-masked];
[email-masked]

What if someone misconfigures the dot zone file and the entire DNS goes
down?

If a DHCPv6 server tells me I have address 2003::2003/68 and then I get
a router advertisement with a prefix option for 2003::/60 then I know
that both 2003::/68 and 2003::/60 are directly connected to my
interface. That the two happen to overlap is somewhat curious, but
otherwise no big deal.

> Further, isn't sending prefix length in DHCPv6 messages duplicating 
> what RA PIO prefix length field already is capable of doing?

Since when is there a requirement that a piece of information may not be
learned through two ways independently?

The point is that if a DHCPv6 server gives out addresses without a
prefix lenght, it only does half a job. Sure, you can let another
protocol pick up the slack and in theory that may not seem like a
problem, but the trouble is that in practice, different protocols run
and possibly fail at different times so the permutations increase
rapidly while if you just put it in the DHCPv6 message and get it over
with, life is simple and we can all go home early.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 17 Aug 2007 11:46:24 +0200

> will not initiate DHCPv6.

Sure, the information will be there MOST of the time, but it's not  
hard to come up with ways in which it won't be there.

> Such a RA can include a prefix and prefix

And how is this a better way to operate than to have that prefix  
length in the DHCP message?

> OK, I deployed DHCPv6 address assignment today.

Well then, what happens if the DHCPv6 server gives out an address and  
the router doesn't supply prefix information for the prefix that  
address falls into? I'm not saying this will happen every day, just  
interested to learn how the implementation that you use handles this.

> Start listing show

Sorry, that's too much work. I can write an email message in a few  
minutes, a draft takes hours of overhead getting all the boilerplate  
and formatting right and then it takes a week before it's published.

Also, few people tend to read random drafts, so it's not an efficient  
way to communicate a simple point.

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 17 Aug 2007 06:59:56 -0700

> will not initiate DHCPv6.

That doesn't make much sense; if a node doesn't hear
RAs, why wouldn't it try DHCPv6 before giving up?

Fred
[email-masked]

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 17 Aug 2007 11:26:42 -0400

Fred,

I have not found any information in the ND RFC's nor DHCPv6 RFC that say
a node can initiate DHCPv6 if node doesn't receive any RA. I need to see
explicit text in some document to accept what you said below.

Hemant

-----Original Message-----
From: Templin, Fred L [mailto:[email-masked]] 
Sent: Friday, August 17, 2007 10:00 AM
To: Hemant Singh (shemant); Iljitsch van Beijnum
Cc: [email-masked]; [email-masked]; JINMEI Tatuya / ????
Subject: RE: [dhcwg] Re: prefix length determination for DHCPv6

> will not initiate DHCPv6.

That doesn't make much sense; if a node doesn't hear RAs, why wouldn't
it try DHCPv6 before giving up?

Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 17 Aug 2007 08:31:48 -0700

> explicit text in some document to accept what you said below.

Is there a MUST NOT somewhere that I am missing?

Fred

---

From: James Carlson <[email-masked]>
Date: Fri, 17 Aug 2007 11:49:27 -0400

> explicit text in some document to accept what you said below.

It does say this.  See RFC 2462 section 4:

   The next phase of autoconfiguration involves obtaining a Router
   Advertisement or determining that no routers are present. If routers
   are present, they will send Router Advertisements that specify what
   sort of autoconfiguration a host should do.  If no routers are
   present, stateful autoconfiguration should be invoked.

And then more forcefully in 5.5.2:

5.5.2.  Absence of Router Advertisements

   If a link has no routers, a host MUST attempt to use stateful
   autoconfiguration to obtain addresses and other configuration
   information. An implementation MAY provide a way to disable the
   invocation of stateful autoconfiguration in this case, but the
   default SHOULD be enabled.  From the perspective of
   autoconfiguration, a link has no routers if no Router Advertisements
   are received after having sent a small number of Router Solicitations
   as described in [DISCOVERY].

It's certainly pointless unless you also have access to some static
prefix information, but it's what the documents say to do.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 17 Aug 2007 12:23:54 -0400

Thanks, James. I agree with Fred then that a node can try DHCPv6. But
now how does the node get a prefix length? As you are saying, some
manual or static configuration can be used. I certainly don't like the
host to assume any prefix length in this scenario. Since I am not a fan
of any manual configuration, it does make sense, only for such a case of
absence of an RA, that DHCPv6 provides prefix length. Since DHCPv6
doesn't know if the network's router will issue RA's or not, then DHCPv6
has to provide prefix length all the time.

Then I am for what Iljitsch is saying. If a host see a discrepancy in
prefix lengths from RA and DHCPv6, then host has to decide based on a
union of information.

Hemant 

-----Original Message-----
From: James Carlson [mailto:[email-masked]] 
Sent: Friday, August 17, 2007 11:49 AM
To: Hemant Singh (shemant)
Cc: Templin, Fred L; Iljitsch van Beijnum; [email-masked];
[email-masked]; JINMEI Tatuya / ????
Subject: RE: [dhcwg] Re: prefix length determination for DHCPv6

Hemant Singh (shemant) writes:
> I have not found any information in the ND RFC's nor DHCPv6 RFC that 
> say a node can initiate DHCPv6 if node doesn't receive any RA. I need 
> to see explicit text in some document to accept what you said below.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 17 Aug 2007 12:38:12 -0400

Ralph,

What all information constitutes prefix information? If a node is DHCPv6
enabled in a RA-absent network, why isn't just the prefix length enough
for the node to make an on-link determination with? In comparison, a
node that is DHCPv6 enabled in a RA-present network uses prefix length
and L bit together to make an on-link determination.

Thanks.

Hemant 

-----Original Message-----
From: Ralph Droms (rdroms) 
Sent: Friday, August 17, 2007 12:27 PM
Subject: 

References:
<[email-masked]><7ECEF9368E169544B43882B
[email-masked]><8E296595B6471A4689555D
[email-masked]><8C324AEB-292B-42E5-A6B6-4
[email-masked]><[email-masked]><FDB
[email-masked]><18113.42485.158453.756815@g
argle.gargle.HOWL><[email-masked]><18115.3756.371573.1032
[email-masked]><[email-masked]><m1zm0reu44.wl%jin
[email-masked]><B00EDD615E3C5344B0FFCBA910CF7E1D038812F0@xmb-
rtp-20e.amer.cisco.com><[email-masked]><
[email-masked]><870
[email-masked]><B00EDD615E3C5344B0FFCBA910C
[email-masked]><39C363776A4E8C4A94691D2BD9D1C9
[email-masked]><B00EDD615E3C5344B0FFCBA910CF7E1
[email-masked]> <18117.50055
[email-masked]>
<[email-masked]>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <[email-masked]>
Cc: "James Carlson" <[email-masked]>,  [email-masked],
"Templin, Fred L" <[email-masked]>,  Iljitsch van Beijnum
<[email-masked]>,  [email-masked],  JINMEI Tatuya / ????
<[email-masked]>
From: Ralph Droms <[email-masked]>
Subject: Re: [dhcwg] Re: prefix length determination for DHCPv6
Date: Fri, 17 Aug 2007 12:27:46 -0400
To: "Hemant Singh (shemant)" <[email-masked]>
FILETIME=[685A1920:01C7E0EB]

Send prefix information, not prefix lengths with assigned addresses.

The little bit of savings in assuming the tie-in between assigned
addresses and on-link prefixes is short-sighted.

- Ralph

> host to assume any prefix length in this scenario. Since I am not a 
> fan of any manual configuration, it does make sense, only for such a 
> case of absence of an RA, that DHCPv6 provides prefix length. Since 
> DHCPv6 doesn't know if the network's router will issue RA's or not, 
> then
> DHCPv6

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

---

From: James Woodyatt <[email-masked]>
Date: Fri, 17 Aug 2007 09:41:33 -0700

On Aug 17, 2007, at 6:59 AM, "Templin, Fred L" <[email-masked] 
 > wrote:

> RAs, why wouldn't it try DHCPv6 before giving up?

It seems to me that the semantic content of RA with M=1 is to signal  
to DHCP-capable nodes that no further delay is necessary... DHCP  
discovery can proceed immediately.

One wonders why they would bother waiting in the first place given the  
significant probability that DHCP service is deployed without any RA  
whatsoever.

So, it seems natural to ask... what good is the M bit anyway?

-jhw

---

From: Ralph Droms <[email-masked]>
Date: Fri, 17 Aug 2007 12:47:34 -0400

Prefix information includes prefixes other than those associated with  
assigned addresses, or the case when the prefix associated with the  
address is not on link.

Admittedly, the latter case is less than useful without a default  
router.  But default router information might come from elsewhere.

Why are we discussing taking a step *backward* in entangling prefix  
information with address assignment, when the separation of those two  
not-necessarily-related functions is one of the things IPv6 actually  
got right?  Please step back from saving a couple of bits and think  
about the abstractions.

- Ralph

On Aug 17, 2007, at Aug 17, 2007,12:38 PM, Hemant Singh ((shemant))  
wrote:

> <C6FE2907-79C0-4EB2-90AC- 
> [email-masked]><7ECEF9368E169544B43882B
> C98EB5D92032DA844@SVR-ALH- 
> EXC-02.mgc.mentorg.com><8E296595B6471A4689555D
> 98139-14EE-4D5F-B96D- 
> [email-masked]><18113.42485.158453.756815@g
> rtp-20e.amer.cisco.com><[email-masked] 
> ><
> 6B8AE-001D-4403- 
> [email-masked]><B00EDD615E3C5344B0FFCBA910C
> F7E1D038813A2@xmb- 
> rtp-20e.amer.cisco.com><39C363776A4E8C4A94691D2BD9D1C9
> A1029ED9C6@XCH- 
> NW-7V2.nw.nos.boeing.com><B00EDD615E3C5344B0FFCBA910CF7E1
> X-Mailer: Apple Mail (2.752.2)
> Return-Path: [email-masked]
> X-OriginalArrivalTime: 17 Aug 2007 16:26:47.0602 (UTC)

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 17 Aug 2007 09:46:22 -0700

> What all information constitutes prefix information?

Why not just have DHCP return the same info as in an
RFC2461 PIO?

Fred

---

From: Ralph Droms <[email-masked]>
Date: Fri, 17 Aug 2007 12:48:28 -0400

You're not the first person to ask that question...

- Ralph

On Aug 17, 2007, at Aug 17, 2007,12:41 PM, James Woodyatt wrote:

> On Aug 17, 2007, at 6:59 AM, "Templin, Fred L"  
> <[email-masked]> wrote:
>
> It seems to me that the semantic content of RA with M=1 is to  
> signal to DHCP-capable nodes that no further delay is necessary...  
> DHCP discovery can proceed immediately.
>
> One wonders why they would bother waiting in the first place given  
> the significant probability that DHCP service is deployed without  
> any RA whatsoever.
>

---

From: James Carlson <[email-masked]>
Date: Fri, 17 Aug 2007 12:33:36 -0400

> has to provide prefix length all the time.

My view on it is that such a network is just plain broken.  V6 seems
intentionally designed to assume that networks have routers, because
routers are the _authoritative_ source of prefixes (they have to route
them).

Thus, it's a case I test for, and one I make sure "works," but I
assume that it's useless.  In my own implementation, you end up with a
/128 for that interface.  If you have a default route, everything will
go there (via the link-locals), and you'll get a pile of redirects for
the local hosts.  If you don't, then you're just sunk.  Enjoy the
address, because it's all you've got.  ;-}

> prefix lengths from RA and DHCPv6, then host has to decide based on a

"Union" doesn't make much sense to me.  That just provides a needless
opportunity for error, and consequent bizarre and hard-to-diagnose
behavior out of subsets of hosts on a network that get the wrong data.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 17 Aug 2007 13:04:24 -0400

Unless anyone can mention a lot of potential IPv6 deployments that will
deploy IPv6 without a router sending RA, it's not even worth discussing
the subject. Don't tell me one will deploy DHCPv6 hosts without a router
in the deployment - don't give me private closed networks for an example
- it's a weak argument. Even a dinky home network I can build in my home
for IPv6 better have the Linksys router sending RA's to IPv6 hosts in my
home. If a router is deployed, then why disable the RA on the router? I
agree with James that such a RA-absent network is plain broken. 

My union statement has been qualified by "if a network has RA and
DHCPv6, both, sending prefix lengths". If such a scenario happens, then
what choice does one have but to resolve discrepancies in data provided
by two sources but to use some sort of union.

>From day one, I am with James and Bernie, that DHCPv6 should not add any
more options towards prefix information or gateway. Let only RA provide
prefix information.

Hemant 

-----Original Message-----
From: James Carlson [mailto:[email-masked]] 
Sent: Friday, August 17, 2007 12:34 PM
To: Hemant Singh (shemant)
Cc: Templin, Fred L; Iljitsch van Beijnum; [email-masked];

> then DHCPv6 has to provide prefix length all the time.

Thus, it's a case I test for, and one I make sure "works," but I assume
that it's useless.  In my own implementation, you end up with a
/128 for that interface.  If you have a default route, everything will
go there (via the link-locals), and you'll get a pile of redirects for
the local hosts.  If you don't, then you're just sunk.  Enjoy the
address, because it's all you've got.  ;-}

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 17 Aug 2007 13:15:30 -0400

Ralph,

I couldn't agree with you more. I don't like entangling prefix
information with address assignment. It is so IPv4 thinking. I am off
this discussion now since I don't believe in any IPv6 network that
deploys DHCPv6 without a router or deployment where the router does not
send RA's. 

Further, I don't believe in sending prefix information that includes
prefixes other than those associated with assigned addresses, just like
I don't believe in any IPv6 network deployed without a router. A host
can just receive prefix length and then host knows from its assigned
address what is on-link for this host - I have assumed this host hasn't
seen any RA because if the host does, then L-bit from RA has to be
combined with prefix length for on-link determination. Any other prefix
will be off-link and let the host send non-link-local traffic to default
router. 

Hemant 

-----Original Message-----
From: Ralph Droms (rdroms) 
Sent: Friday, August 17, 2007 12:48 PM
To: IETF List IPv6 Mailing; [email-masked]
Subject: [dhcwg] Re: RE: 

Why are we discussing taking a step *backward* in entangling prefix
information with address assignment, when the separation of those two
not-necessarily-related functions is one of the things IPv6 actually got
right?  Please step back from saving a couple of bits and think about
the abstractions.

- Ralph

wrote:

> [email-masked]><[email-masked]><F

> DB
> argle.gargle.HOWL><[email-masked]><18115.3756.371573.10

> 32
> [email-masked]><B00EDD615E3C5344B0FFCBA910CF7E1D038812F0@xm

> b-

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 17 Aug 2007 10:17:47 -0700

> the subject.

ISATAP links have routers that send RAs, but not all nodes on
the link will necessarily receive them. A node on an ISATAP
link can always send an RS to get back an RA, but why bother
when the information is available via DHCP?
  
> Don't tell me one will deploy DHCPv6 hosts without a router
> in the deployment

Not hearing unsolicited RAs is not the same thing as not
having routers.

> - don't give me private closed networks for an example
> home.

OK.

> If a router is deployed, then why disable the RA on the router? I

It's not about disabling RA on the router at all; the
routers are just ordinary routers and will still send
RAs just fine. 

Fred

---

From: Ralph Droms <[email-masked]>
Date: Fri, 17 Aug 2007 13:29:32 -0400

"Beliefs" are irrelevant; we need to consider facts and requirements.

Assigned addresses have nothing intrinsically to do with on-link.  In  
the common case, an address on an interface is quite likely to be in  
a prefix that is on-link.  But on-link-ness is a property used for  
outbound traffic, while an address on an interface is used to filter  
inbound traffic.  The IPv6 design decision has been to separate those  
two notions.

I know of no "MUST NOT" that precludes hosts on a network with no RAs  
having addresses from different prefixes; i.e., host A has an address  
from 2001:0:0:1::/64 and host B has an address from 2001:0:0:ffff::/ 
64.  If host A is going to communicate with host B, one of the two  
hosts is going to have to know about the other host's prefix.  So, if  
DHCPv6 is used, DHCPv6 will need to carry other prefix information  
aside from those in the address assigned to the host.

- Ralph

On Aug 17, 2007, at Aug 17, 2007,1:15 PM, Hemant Singh ((shemant))

---

From: Ralph Droms <[email-masked]>
Date: Fri, 17 Aug 2007 13:38:40 -0400

Jinmei-san - I fully agree that it would be a good idea to hold off  
on this discussion until an I-D is published.

One small correction...the originators of the discussion about "rogue  
RAs" are network admins who have real-world experience with IPv6  
deployments.  I wouldn't consider them as "DHCPv6 guys" in this  
context...

- Ralph

On Aug 11, 2007, at Aug 11, 2007,4:51 AM, JINMEI Tatuya / 神明達哉

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 17 Aug 2007 20:36:55 +0200

> So, it seems natural to ask... what good is the M bit anyway?

To stop unnecessary DHCP traffic. Please don't make implementations  
do DHCP by default even without an M or O bit, as I've said before,  
multicast traffic uses up inordinate amounts of bandwidth on wifi  
links and it's even worse if there are no DHCPv6 servers (which is  
the case in 99.99% of all deployments today) so the requests will be  
retransmitted.

---

From: james woodyatt <[email-masked]>
Date: Fri, 17 Aug 2007 13:09:26 -0700

On Aug 17, 2007, at 11:36, Iljitsch van Beijnum wrote:
>
> To stop unnecessary DHCP traffic. [...]

I think what we're seeing here is a vocal faction of the community  
who believe that DHCP discovery multicasts are always necessary,  
whether RA is present or not, and whether M=0 or M=1, despite the  
text in RFC 2462.

Here's what they seem to be saying: wherever a DHCP server *may* be  
present, DHCP discovery *MUST NOT* be prevented and *SHOULD NOT* be  
delayed.  If you agree with that, then perhaps it also makes sense to  
move prefix and default gateway assignment into DHCP for the purpose  
of improving efficiency.  The DHCP advocates seem to view RA with M=1  
as basically superfluous to the process, unless it can be made to  
signal effectively that nodes *MUST NOT* perform stateless  
autoconfiguration.  Alas, unfortunately for them, RFC 2462 doesn't do  
that.  In fact, it explicitly states that a node *may* always perform  
stateless autoconf after receiving RA with M=0 containing a PIO with  
A=1, and hence the kvetching about rogue advertisers.

There is a closely related problem here in the language of RFC 2462.   
Notice how the state of the ManagedFlag conceptual variable is  
specified during processing of Router Advertisements.

> Section 5.2 Autoconfiguration-Related Variables
>
>  Hosts maintain the following variables on a per-interface basis:
>
>       ManagedFlag      Copied from the M flag field (i.e., the
>                        "managed address configuration" flag) of the  
> most
>                        recently received Router Advertisement message.
>                        The flag indicates whether or not addresses are
>                        to be configured using the stateful
>                        autoconfiguration mechanism. It starts out in a
>                        FALSE state.
[...]
> 5.5.3.  Router Advertisement Processing
>
>    On receipt of a valid Router Advertisement (as defined in
>    [DISCOVERY]), a host copies the value of the advertisement's M bit
>    into ManagedFlag. If the value of ManagedFlag changes from FALSE to
>    TRUE, and the host is not already running the stateful address
>    autoconfiguration protocol, the host should invoke the stateful
>    address autoconfiguration protocol, requesting both address
>    information and other information.  If the value of the ManagedFlag
>    changes from TRUE to FALSE, the host should continue running the
>    stateful address autoconfiguration, i.e., the change in the  
> value of
>    the ManagedFlag has no effect.  If the value of the flag stays
>    unchanged, no special action takes place. In particular, a host  
> MUST
>    NOT reinvoke stateful address configuration if it is already
>    participating in the stateful protocol as a result of an earlier
>    advertisement.

I see only one invocation of RFC 2119 requirements language in there,  
and it's to apply a curious injunction not to restart DHCP discovery  
every time RA with M=1 is received while ManagedFlag is TRUE.  All  
the rest of the verbiage about the ManagedFlag conceptual variable  
amounts to a recommendation that DHCP discovery should be deferred  
until the first receipt of RA with M=1 at the interface and should  
remain in operation until the interface disconnects.  One interesting  
consequence of this verbiage is that it recommends setting the  
ManagedFlag to FALSE upon receiving RA with M=0.  When the next RA  
arrives with M=1, the node will then be free to restart DHCP  
discovery because the above requirement will no longer apply.   
(Whether it *will* is not specified.)  This basically nullifies the  
utility of the one instance of RFC 2119 requirements language in how  
the ManagedFlag is to be handled during RA processing.

As I said, it's very curious.

I think the new 6MAN working group should take up a project of  
clarifying the requirements for processing router advertisements in  
IPv6 nodes.

On a related note, I've heard that some operators intend to deploy  
DHCP service using RA with M=1 and no PIO.  I don't understand how  
they imagine the "on-link flag" to be propagated in that scenario.   
The "on-link flag" seems to be clearly in the domain of router  
function, not dynamic node configuration.  Is that to be described in  
the forthcoming Internet draft?

---

From: James Carlson <[email-masked]>
Date: Fri, 17 Aug 2007 16:22:57 -0400

> >    TRUE, and the host is not already running the stateful address
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >    autoconfiguration protocol, the host should invoke the stateful
       ^^^^^^^^^^^^^^^^^^^^^^^^^^
[...]
> discovery because the above requirement will no longer apply.   

No, it won't be free to do so.  The text quoted above makes it fairly
clear that if you're already running the stateful address protocol,
you don't restart it.  Even if the flag changes from FALSE to TRUE.

It's a one-shot event on a given interface.  If you time out waiting
to hear from routers, or if any router anywhere ever tells you to run
DHCPv6 on that interface, then that's what you do.  The only time you
_don't_ run DHCPv6 is when you (A) consistently hear from routers and
(B) those routers all tell you M=0 and O=0.

(Reserve a special place for naming a bit 'O'.  ;-})

---

From: james woodyatt <[email-masked]>
Date: Fri, 17 Aug 2007 16:45:23 -0700

>>>    TRUE, and the host is not already running the stateful address

You're right.  My mistake.  The sentence preceding the requirement  
doesn't specify an actual contingency.  The requirement applies  
regardless of the current state of the ManagedFlag.  Once the  
stateful autoconfiguration protocol starts, it's expected to continue  
without restarting until the interface disconnects from the link.

> (B) those routers all tell you M=0 and O=0.

I don't see any MUST NOT that requires stateless AddrConf to be  
deferred while the node waits "for a time" to receive of RA with  
M=1.  If the typical network with DHCP service never has any  
legitimate routers sending RA of any sort, then nodes will typically  
acquire service more quickly after connecting if they do not wait for  
packets that will never arrive.  Since there is no RFC 2119  
requirement to wait, a conforming implementation can certainly choose  
not to defer DHCP discovery while prefix discovery has not yet  
completed, despite the informative text suggesting that waiting is  
appropriate.

Whether DHCP6 must not complete until prefix discovery has completed  
is an open question, or so it seems to me after reading RFC 3315 and  
looking for guidance on the subject.  I suspect I would prefer to see  
RFC 3315 revised to define a new IA_PI (prefix information) option  
for clients to use, which would associate a list of discovered  
prefixes with their generated IAID.  Clients that send Solicit  
messages containing IA_TA or IA_NA options without an accompanying  
IA_PI option will be implying that they failed or refused to discover  
any prefixes.  Servers may then refuse to send Advertise messages to  
clients that have no acceptable prefixes.  When clients provide a  
IA_PI option, then servers are required to assign addresses from the  
specified list of prefixes.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 17 Aug 2007 20:31:36 -0400

James,

Wrt to what you asked as follows put within square brackets by me
followed by my reply.

[On a related note, I've heard that some operators intend to deploy DHCP
service using RA with M=1 and no PIO.  I don't understand how  
they imagine the "on-link flag" to be propagated in that scenario.   
The "on-link flag" seems to be clearly in the domain of router function,
not dynamic node configuration.  Is that to be described in the
forthcoming Internet draft?]

In an aggregation router network, all host behind broadband modems are
always off-link as we have explained in this mailer - see one of my
emails.

So there is NO NEED to propagate any on-link flag is such a network. 

The physical connectivity of such networks prohibits hosts behind modems
to talk directly to each other even when a pair of hosts are in the same
link. The hosts have to send their traffic to the aggregation router.
That is why IPv6 hosts in an aggregation router deployment are always
off-link. So how does one signal off-link in RA? One way is to send no
PIO in RA. See section 2.1 of our I-D for how this signals off-link, and
under what conditions, and for what IPv6 addresses (link-local or
non-link-local addresses). Our I-D is at:

http://www.ietf.org/internet-drafts/draft-wbeebee-nd-implementation-pitf
alls-02.txt
 
Do read section 3 of our I-D that described aggregation routed
deployments. 

While I have everyone here, when will folks agree that some cases for
on-link determination are not clear in 2461bis and such cases need to be
clarified - that is the reason we wrote the I-D above. If on- vs.
off-link is not clear, data forwarding and address resolution of
behavior of hosts gets affected - these are key features of a host
operation and hence on- vs. off-link should be crystal clear! Maybe our
late-breaking I-D was a bad timing for 2461bis authors, but the facts
still remain that our I-D is worth an Implementation Guideline and be
considered as a WG item for v6man. That is why we have also collected
some bugs in IPv6 ND implementation and listed them in section 7 of our
I-D keeping the format of the bugs ala RFC 2525.

Do humor me and let I and Wes know how many other ways exist for an RA
to be specified to signal off-link mode to hosts?

Hemant 

-----Original Message-----
From: james woodyatt [mailto:[email-masked]] 
Sent: Friday, August 17, 2007 4:09 PM
To: IETF IPv6 Mailing List; [email-masked]
Subject: Re: [dhcwg] Re: prefix length determination for DHCPv6

> To stop unnecessary DHCP traffic. [...]

I think what we're seeing here is a vocal faction of the community who
believe that DHCP discovery multicasts are always necessary, whether RA
is present or not, and whether M=0 or M=1, despite the text in RFC 2462.

Here's what they seem to be saying: wherever a DHCP server *may* be
present, DHCP discovery *MUST NOT* be prevented and *SHOULD NOT* be
delayed.  If you agree with that, then perhaps it also makes sense to
move prefix and default gateway assignment into DHCP for the purpose of
improving efficiency.  The DHCP advocates seem to view RA with M=1 as
basically superfluous to the process, unless it can be made to signal
effectively that nodes *MUST NOT* perform stateless autoconfiguration.
Alas, unfortunately for them, RFC 2462 doesn't do that.  In fact, it
explicitly states that a node *may* always perform stateless autoconf
after receiving RA with M=0 containing a PIO with A=1, and hence the
kvetching about rogue advertisers.

There is a closely related problem here in the language of RFC 2462.   
Notice how the state of the ManagedFlag conceptual variable is specified
during processing of Router Advertisements.

[...]
>    stateful address autoconfiguration, i.e., the change in the value 
> of

I see only one invocation of RFC 2119 requirements language in there,
and it's to apply a curious injunction not to restart DHCP discovery
every time RA with M=1 is received while ManagedFlag is TRUE.  All the
rest of the verbiage about the ManagedFlag conceptual variable amounts
to a recommendation that DHCP discovery should be deferred until the
first receipt of RA with M=1 at the interface and should remain in
operation until the interface disconnects.  One interesting consequence
of this verbiage is that it recommends setting the ManagedFlag to FALSE
upon receiving RA with M=0.  When the next RA arrives with M=1, the node
will then be free to restart DHCP  
discovery because the above requirement will no longer apply.   
(Whether it *will* is not specified.)  This basically nullifies the
utility of the one instance of RFC 2119 requirements language in how the
ManagedFlag is to be handled during RA processing.

On a related note, I've heard that some operators intend to deploy DHCP
service using RA with M=1 and no PIO.  I don't understand how  
they imagine the "on-link flag" to be propagated in that scenario.   
The "on-link flag" seems to be clearly in the domain of router function,
not dynamic node configuration.  Is that to be described in the
forthcoming Internet draft?

---

From: james woodyatt <[email-masked]>
Date: Fri, 17 Aug 2007 18:29:05 -0700

On Aug 17, 2007, at 17:31, Hemant Singh (shemant) wrote:
> [I wrote:]
>> DHCP
>> function,

I suppose accepting the consequences of not being able to propagate  
the "on-link flag" is one way to handle the problem.  I hope section  
2.1 of the ND Implementation Pitfalls draft will be reviewed  
carefully by everyone participating in the discussions about prefix  
length determination in DHCP6.

---

From: "Michael W. Oliver" <[email-masked]>
Date: Fri, 17 Aug 2007 11:48:43 -0400

On 2007-08-17T06:59:56-0700, Templin, Fred L wrote:
>> transactions because unless the host sees an RA with M bit set the
>> host will not initiate DHCPv6.
> 

I agree.

If you are sending RAs from your router and simultaneously need to have
a node delegated a different length prefix than what is provided by the
RA, then DHCPv6 is the place to do it.  If there is no prefix length
specified in the DHCPv6 offer then the prefix length from the RA wins,
else DHCPv6 wins.  I can't think of any reason off of the top of my head
to do so, but why forbid the option?

If you aren't sending RAs from your router (the reasons for not sending
RAs notwithstanding), as Fred eludes, then the node needs to learn the
prefix length along with the address via DHCPv6.  If DHCPv6d authors
want to make it hard to turn this knob so that admins don't
inadvertently advertise inconsistent prefix lengths, that's their
choice, but to forbid the option in the specification seems wrong.

Regards,
Mike

-- 
Mike Oliver, KI4OFU
[see complete headers for contact information]
+----------------------------------------------------------------------+
| KI4OFU      When all else fails...AMATEUR RADIO THRIVES!      KI4OFU |
+----------------------------------------------------------------------+
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 19 Aug 2007 14:15:23 +0200

On 18-aug-2007, at 17:37, Ralph Droms wrote:

> Therefore there is no need to provide a prefix length with an  
> assigned IPv6 address, whether that address is assigned through  
> SLAAC, DHCPv6, manual assignment or divine intervention.

Obviously we're not making progress here so I'm stopping my  
retransmissions.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 19 Aug 2007 14:50:17 +0200

> whether RA is present or not, and whether M=0 or M=1, despite the  

Right.

Over the course of this dicussion and remembering the previous ones  
about the M and O bits and what to do about DNS resolver  
configuration, I've reached the conclusion that DHCPv6 the way it is  
now is too incompatible with other aspects of IPv6 the way they are  
now. Also, even if we ignore the resulting difficulties, there are  
several needs that aren't met today. So I think it would be a good  
idea to take a leap forward and come up with something that actually  
does what we want rather than keep reinterpreting existing  
specifications and implementation behavior.

The goal is to make server-assisted autoconfiguration much more  
useful, and reduce the number of packets in general and multicast  
packets in particular, as well as any delays or timeouts in the  
autoconfiguration process.

The first step is to add an option to the router solicitation message  
that makes it possible to use this message as the start of a DHCP  
exchange. This way, a host doesn't have to know whether it will  
receive configuration through RAs or DHCP or both, and there is no  
delay if there are no RAs. I'm not sure whether the option should  
have a DUID identifier in it or that a small cookie that the DHCP  
server can recognize to see if the host needs new configuration is  
more efficient. Preferably, the option should be no larger than the  
minimum 8 bytes option size.

When the option is seen in a router solicitation, the info is  
forwarded through regular DHCP forwarders, or possibly be turned into  
an existing DHCP message for backward compatibility. Obviously DHCP  
servers on the link will listen for the messages directly. It is the  
job of the DHCP server to determine what type of configuration the  
host requires and respond with a unicast message if a response is  
needed. I'm thinking there are three types of configuration information:

- "shared" other configuration (= configuration items that are the  
same for all hosts on a link)
- host-specific but stateless configuration (i.e., if the DHCP server  
loses state it will still return the same configuration information  
later)
- stateful configuration

In most cases, the shared other configuration shouldn't be sent out  
by a DHCP server, but rather, be included in router advertisements.  
To make this simpler, router advertisements gain the capability to  
include DHCP options.

A new DHCP capability is address registration. This means that the  
host selects one or more addresses autonomously, and then tells the  
DHCP server about those addresses, for the following purposes:

- to avoid DAD
- to allow administrators to know which host uses which address at  
any given time
- to open up firewall holes
- to register addresses in the DNS

I'm not current on the work to reduce duplicate address detection,  
but unless I'm mistaken it should be possible to skip DAD on any  
address derived from an EUI-64 with the global/local bit set to  
"global". If all nodes that use these addresses do in fact derive  
them from an EUI-64 or 48-bit MAC address, then the only way a  
duplicate can happen is when there is a duplicate MAC address and  
then DAD is moot because communication can't happen anyway.

For all other addresses used on multiple access networks, i.e., ones  
where the g/l bit is set to "local" or where no 64-bit interface  
identifier was used because the subnet size is different than /64,  
it's necessary to make sure there are no duplicates. The idea here is  
that DAD and therefore several multicast packets and a timeout can be  
avoided by having a DHCP server keep track of the addresses that are  
in use on a subnet.

I'm assuming the other three uses speak for themselves.

I realize all of this requires significant extra work, but the upside  
is that it will give us a streamlined way to do autoconfiguration,  
both in the case where there is no coordination beyond a router  
advertising its presence and one or more prefixes, in the case where  
everything is managed and in the continuum inbetween, as opposed to  
the current toolbox of loosely related mechanisms that we have a hard  
time getting to work together well.

Obviously the above is only a fairly rough idea, there are lots of  
things to be worked out. If anyone is interested in working on this,  
please let me know in a private message.

---

From: James Carlson <[email-masked]>
Date: Mon, 20 Aug 2007 09:02:29 -0400

> delay if there are no RAs. I'm not sure whether the option should  

I don't see what that fixes.  It appears to reduce the traffic from
three packets {RS, RA, DHCP Solicit} down to two {RS, RA "Enhanced"},
but I'm not sure why that's an important consideration.  Is getting
rid of one packet per link start-up a useful thing to do when it also
means that DHCPv6 servers and routers will be architecturally joined
at the hip, limiting deployment options, and when it means that
Proposed Standard documents need to be roto-tilled?

To me, that sounds like high cost with essentially no benefit.  What
am I missing?

> DHCP server about those addresses, for the following purposes:

You can already do that if you want.  See RFC 3315 section 18.1.1 --
you can include IAs for the addresses you want or already have in your
DHCP Request message.

> - to avoid DAD

Avoiding DAD doesn't sound like a good goal to me.  It means that the
system _assumes_ that the rest of the world is perfect and never has
any problems.

But do what you feel you must on your own networks and in your own
products.

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 21 Aug 2007 10:36:07 +0900

> deploy IPv6 without a router sending RA, it's not even worth discussing

I pointed it out several times in IPv6 related WGs that RA work poorly
over links with unreliable multicast/broadcast, such as wireless LANs.

ND is designed so poorly that it barely works only over Ethernet
and PPP.

Don't expect ND reasonably work even over Ethernet.

							Masataka Ohta

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 21 Aug 2007 11:38:20 +0200

> To me, that sounds like high cost with essentially no benefit.  What

What it does and saves is very much dependent on the circumstances.

Saving one or two packets here or there in and of itself is probably  
not compelling (but a good secondary goal because those multicasts  
can clog up wireless networks). The main benefit is that it  
simplifies the host behavior: rather than either holding off on DHCP  
depending on value of the M and O bits, which costs extra time, or  
ignoring the M and O bits and adding a fairly significant number of  
discovery packets, a host can always do the same thing and reach the  
optimum result as fast as possible, regardless of whether the network  
runs with RAs only, stateless autoconfig + DHCP for other  
configuration, stateless autoconfig + stateful config combined, RAs  
but no stateless autoconfig with DHCP, or even no RAs at all and just  
DHCP. The way things are now, host behavior will be suboptimal for at  
least some of these situations.

> you can include IAs for the addresses you want or already have in your

Excellent.

> system _assumes_ that the rest of the world is perfect and never has

Let me rephrase: making DAD more efficient. If there's a DHCP server  
present that knows about all addresses anyway, then obviously the  
DHCP server is capable of determining whether two nodes are trying to  
use the same address, which is probably more efficient than hosts  
doing DAD for each address.

Personally, I'm comfortable with foregoing DAD on EUI-64 derived  
addresses, because if the EUI-64 uniqueness fails things aren't going  
to work anyway. There is always the possibility of someone  
configuring a duplicate EUI-64 address manually, though, so there is  
still _some_ potential for trouble. So I guess no DAD for EUI-64 or  
DAD for everything is something that network administrators should be  
able to control.

---

From: Markku Savela <[email-masked]>
Date: Tue, 21 Aug 2007 13:08:21 +0300

> doing DAD for each address.

I wouldn't trust DHCP server totally -- I've had my run of broken(?)
DHCP setups, which do give address that is already use (probably some
DHCP proxy issue). The life saver was that host did DAD, detected
duplicate and asked another address, all was fine.... until it
happened that the other address too was in use and host was stuck
because DHCP kept giving the same two alternate addresses.

I would do DAD by default on any configured address, regardless
of the way it was selected (manual, DHCP or whatever).

Even with IPv6 I see many ways of getting DCHP servers view of
addresses currently in use getting out of synch ("intelligent
switches" might be one cause, when host is moved from one segment to
another, and switch routes by learned MAC incorrectly ...)

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Tue, 21 Aug 2007 07:02:10 -0400

And, there's always the case where the DHCP server has lost it memory
(i.e. disk) - in that case it would have no idea what was or was not
leased.

- Bernie 

-----Original Message-----
From: Markku Savela [mailto:[email-masked]] 
Sent: Tuesday, August 21, 2007 6:08 AM
To: [email-masked]
Subject: Re: Rethinking autoconfig,was Re: prefix length determination
for DHCPv6

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 21 Aug 2007 13:25:33 +0200

> (i.e. disk) - in that case it would have no idea what was or was not

Yes, the server would have to tell nodes to do DAD until all the  
leases from before the reboot have expired.

---

From: James Carlson <[email-masked]>
Date: Tue, 21 Aug 2007 08:52:49 -0400

> simplifies the host behavior: rather than either holding off on DHCP  

Actually, it doesn't do that either.

It doesn't do that because we _already_ have deployed implementations
of all of the existing protocols.  There are systems out there that
already have separate router discovery and DHCP, already work, and
that are unlikely to be "upgraded" at any point in the near future --
if ever at all.

Because of that, any robust implementation of the scheme you're
suggesting would need to support _both_ types of operation.  That
includes most sane vendors: they'll be forced to implement, test, and
support both modes of operation in all of their products.

The alternative leads to an interoperability problem.  A new-style
client introduced into an old-style network won't get the
all-inclusive RAs with DHCP data that it wants, and will then be
forced to drop back to the previous (now existing) mode of operation
with DHCP Solicit.

Thus, adding new features like you're suggesting is always more
complex.  It's only by _removing_ features that we can make things
simpler.

> doing DAD for each address.

This means that the DHCP server is perfect in its operation and
omniscient about all hosts that may be attached to the network, even
the statically-configured ones.

I've yet to meet one that is this good.

> DAD for everything is something that network administrators should be  

I have no problem with implementations including a tunable to disable
DAD for the people who like to work without a net (both figuratively
and literally), but the default still ought to be to use DAD, and
nothing DHCPv6 does ought to discourage that.

To use a phrase from another era: "trust, but verify."

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Tue, 21 Aug 2007 22:07:53 +0900 (JST)

<rant>i wonder how many of those who are voicing opinion here are
	actually using IPv6 in a daily basis.</rant>

itojun

---

From: James Carlson <[email-masked]>
Date: Tue, 21 Aug 2007 09:42:14 -0400

> 	actually using IPv6 in a daily basis.</rant>

I am.  Does that help?

---

From: Shane Kerr <[email-masked]>
Date: Tue, 21 Aug 2007 14:33:21 +0200

james woodyatt wrote:
> IETF will abandon it in favor of a system that more coherently addresses
> the various separate concerns that DHCPv6 attempts to meet.  I hope the
> DHC WG will specify requirements for routers sending advertisements with
> the M bit set that prevent any ambiguity from arising at the node during
> link configuration.
> 
> p.s. I really wish IETF had deprecated DHCPv6 when it had the chance. 
> Every last thing DHCPv6 does belongs in one of two other, separate
> domains, i.e. either in the sub-IP layer, e.g. EAP, or at the
> sub-application layer, e.g. DNS-SD.  Instead, IETF chose a short-sighted
> and half-baked solution to a problem that really didn't need a rush job
> to solve, and the engineering community today is poorer for it.

We need DHCP.

DHCP is used by administrators to do a lot more than simply assign IP
addresses. It is an extremely flexible protocol, and works for lots of
different models of network topology and administrative setup. Any
protocol which did the work that DHCP does would end up looking
suspiciously like DHCP at the end (RFC 3315 gets my vote as one of the
clearest, easiest to implement RFCs, BTW).

I know there's a lot of anti-DHCP sentiment, especially in the IPv6
crowd. I think it is misplaced; DHCP is at worst a necessary evil, and
at best an elegant solution to the problem space where it sits.

Router advertisements cannot do what DHCP does. An RA can carry a
small bit of information, but as a full replacement, the idea falls
flat. You don't always want to broadcast the same information to all
clients. Some hosts want vendor-specific information that will never
be standardized into an RA. A few people may even want to authenticate
their hosts' configurations. And on and on...

At the most basic level, a computer connecting to the network expects to
get an IP address, routing information, and DNS information. Until *last
year*, there was no standard way to get DNS information from an RA. Now
that this "problem" has been solved (*), what next? What about other
basic things like updating the reverse DNS information? What about being
able to log when a given IP was in use for legal, or (far more
importantly) billing purposes?

(*) I put "problem" in quotes because you could use DHCPv6 for this
    since 2003 or so.

It may be possible to force much of this information in to RAs, having
multiple protocols to do one thing is a bad idea, right?

We need DHCP - in IPv6 as much as in IPv4 - so can we please let this
idea that we can do everything in RA die? Please?

- --
Shane

---

From: Ralph Droms <[email-masked]>
Date: Tue, 21 Aug 2007 10:25:31 -0400

I don't use or administer IPv6 on a daily basis. I do run an IPv6  
testbed and experiment with various clients against the Cisco IOS and  
CNR DHCP servers, so I have some experience with host configuration  
using SLAAC, DHCP, SLAAC+DHCP...

- Ralph

On Aug 21, 2007, at Aug 21, 2007,9:07 AM, Jun-ichiro itojun Hagino

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Tue, 21 Aug 2007 10:50:46 -0400

Best to just always have the nodes to DAD. The cost of a DAD message is
pretty low. I'm only recommending this on Ethernet-like networks. If you
have a low-bandwidth network or don't have a shared media, your physical
link layer documents may specify not to do DAD.

- Bernie 

-----Original Message-----
From: Iljitsch van Beijnum [mailto:[email-masked]] 
Sent: Tuesday, August 21, 2007 7:26 AM
To: Bernie Volz (volz)
Cc: Markku Savela; [email-masked]
Subject: Re: Rethinking autoconfig, was Re: prefix length determination
for DHCPv6

---

From: james woodyatt <[email-masked]>
Date: Tue, 21 Aug 2007 12:22:04 -0700

On Aug 21, 2007, at 05:33, Shane Kerr wrote:
>
> [...] having multiple protocols to do one thing is a bad idea, right?

Yes, but having one protocol to do multiple things in cross-cutting  
problem domains is a bad idea, too.

> We need DHCP - in IPv6 as much as in IPv4 - so can we please let  
> this idea that we can do everything in RA die? Please?

I don't want to see RA get bloated out with all the functions  
currently jammed into DHCP.  That would only expand the boundaries of  
the current trouble, rather than addressing any real problems.  I'd  
prefer to see the functions of DHCP split into profiles of other  
existing protocols, e.g. EAP, IKE, DNS-SD, etc.  Any additions to RA  
needed to facilitate those operations should be strenuously avoided.

My major philosophical complaints about DHCP are that it (a) wastes  
multicast network resources doing unnecessary infrastructure  
discovery, (b) conflates interface address and node authorization  
identity for accounting purposes, and (c) complicates network  
configuration by drawing an unnecessary distinction between host  
configuration and other application data.  I realize that others have  
differing opinions, and I fully respect them.  These are mine, and if  
you don't like them, then I have others.

I don't agree that we *need* DHCP, but I'll agree that we *have* DHCP  
and it makes practical sense to use it in the interim while we  
develop a more practical alternative.  We need something better than  
DHCP.  It's just *not* a very good hammer-- and, you know what they  
say: when all you have is a hammer, everything begins to look like a  
folk singer.

---

From: "David W. Hankins" <[email-masked]>
Date: Tue, 21 Aug 2007 10:34:44 -0700

> 	actually using IPv6 in a daily basis.</rant>

ISC is native IPv6, no tunnels (except to employees' homes), dual
stack.

We are, proverbially, "soaking in it."

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 22 Aug 2007 08:59:20 +0900

Right.

The problem is that so called "stateless autoconfiguration" has never
been a well defined concept and is no better than DHCP.

Problem space of ND is not well defined, either, which causes a lot
of troubles.

For example, timing constraints of RFC2462 are often annoying.

As a result, RFC3775 denies RFC2462 that:

   o  MinRtrAdvInterval 0.03 seconds

   o  MaxRtrAdvInterval 0.07 seconds

   RFC 2462 [13] specifies that in normal processing for Duplicate
   Address Detection, the node SHOULD delay sending the initial Neighbor
   Solicitation message by a random delay between 0 and
   MAX_RTR_SOLICITATION_DELAY.  Since delaying DAD can result in
   significant delays in configuring a new care-of address when the
   Mobile Node moves to a new link, the Mobile Node preferably SHOULD
   NOT delay DAD when configuring a new care-of address.

which is an evidence that problem space of ND excluded mobile
environment.

Like that, it is natural that DHCP people think DAD annoying.

							Masataka Ohta

---

From: Mark Smith <[email-masked]>
Date: Thu, 23 Aug 2007 18:50:25 +0930

On Tue, 21 Aug 2007 08:52:49 -0400

<snip>
> I've yet to meet one that is this good.

Agree, and then you also get people like me who occasionally, in a
desperate situation, do a dirty, dirty thing like steal one of the DHCP
server's dynamic addresses for a static assignment, and rely on DAD by
both the DHCP and other hosts to avoid conflicts, while I deal with
the desperate situation.

I don't like doing that sort of thing, but I like that both the DHCP
server and hosts are robust enough to handle it gracefully when I do. A
few extra packets seems to me to be a relatively small price to pay for
robustness and resilience.

Regards,
Mark.

---

From: [email-masked]
Date: Sat, 25 Aug 2007 03:03:08 -0400 (EDT)

I was attempting to get to the bottom of what is, to me, a mystery:

Why does IPv6 use EUI-64 for Interface Identifiers, instead of MAC-48?

The previous version of the RFCs used MAC-48. There seems to have been,
at some point, some discussion regarding the difference between EUI-48 and
MAC-48, as relate to their use in EUI-64.

And the mailing list archives only go back to some time in 2003, while the
RFCs are 1998 (current) and 1996 (replaced by 1998 versions).

As far as I can tell, synthesis of II's relies on adding a fixed 16-bit
value.

Did we collectively just throw away 16 bits of usable space from our 128,
for no good reason?

That's what it looks like to me...

If someone can explain the rationale, that'd be great.

(I suppose it's a bit late in the game to go back to MAC-48 as II?)

BTW - this isn't just a pedantic question, it bears on the policies that
depend on the autoconfiguration prefix size, for minimum prefix size that
is useable, which relates to address allocation policies by RIRs.

Thanks in advance, to anyone who can shed light on this...

Brian Dickson

P.S. 48 bits of MAC is more than enough, I believe, for a few more
centuries of network growth and device/node assignments... so why we would
jump the gun so soon, appears rather odd to me.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 28 Aug 2007 12:11:00 -0400

> robustness and resilience.

I'm surprised that you would manually allocate an IPv6 address,  
although I can understand why you might do that with an IPv4  
address.   The DHCPv4 server unicasts an ICMP Echo request to verify  
the address, which acts as a first-line defense against conflicts due  
to manual allocation.   The client further ARPs for the IP address  
before using it, which acts as a second line of defense.   I'd be  
surprised if either technique was required to have a working DHCPv6  
service - the likelihood of a scarcity-induced address conflict is so  
small.

---

From: Thomas Narten <[email-masked]>
Date: Wed, 29 Aug 2007 10:23:26 -0400

> RFCs are 1998 (current) and 1996 (replaced by 1998 versions).

The IPv6 WG was (previousl) the ipng WG. See the archives at
ftp://ftp.ietf.org/ietf-mail-archive/ipngwg/

> Did we collectively just throw away 16 bits of usable space from our 128,

It kind of looks that way today. :-(

> If someone can explain the rationale, that'd be great.

Well, there were multiple ones. But the main one I recall was that it
made the address format more "friendly" to the 8+8/GSE proposal, with
the hope being that maybe we could still develop 8+8/GSE and have it
work with easily with IPv6. As we know now, that never happened.

The other factor was that there was the thought that future LAN
devices would use 64-bit MAC addresses, i.e., EUI-64
identifiers. Thus, we simply made stateless address autoconfiguration
forwards compatible.

The reality, of course, is that the Ethernet frame format continues
to dominate networking at the edges, and probably will more-or-less
forever.

> (I suppose it's a bit late in the game to go back to MAC-48 as II?)

Yes. The difficulty is figuring out how to move to something different
in a backwards-compatable way. I.e., we'd need a transition strategy.

Thomas

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 29 Aug 2007 16:50:48 +0200

> to dominate networking at the edges, and probably will more-or-less

Firewire has 64-bit MAC addresses but on the Mac (ha) they show up as:

fw0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 494
         lladdr 00:1b:63:ff:fe:7b:41:5c

(Not sure what the deal is with the MTU, normally it's 4078.)

> in a backwards-compatable way. I.e., we'd need a transition strategy.

But what would be the point of doing that now?

The fact that we have so many local bits in the IPv6 address is our  
insurance policy against address policy screwups because a single /64  
is enough to run a network of arbitrary size if you forego stateless  
autoconfig.

---

From: [email-masked]
Date: Wed, 29 Aug 2007 11:17:33 -0400 (EDT)

> But what would be the point of doing that now?

The point, which I have avoided making until now, is that II has direct
impact on the available range of assignments by RIRs to LIRs, for PI blocks,
that also allow for very long timescale predictive assignments.

Basically, the minimum prefix size * number of assignments * LIRs,
when projected over a timeframe of decades, while preserving a global
DFZ consisting of one PI block per LIR, has a problem fitting into the
number of bits per RIR.

Right now, RIRs are reserving only an additional 2 bits per LIR assignment,
for "growth". Alternative allocation policies (bisection) don't guarantee
the ability to assign arbitrarily large blocks indefinitely - while that
is in fact the long-term requirement. Block sizes *should* increase over
time, even as the frequency of their assignment decreases.

What works best is, a best-fit approach, where any organization gets way
more space than they need, sized according to their own best guess as to
long-term growth *potential*.

Then, reserve even more space for each, in a consistent manner.

Take all these requests, and fill them in an optimized space-packing manner.

At some point, growth requests get filled via "growing" the assignment for
a given LIR into its reserved space.

And, long-term periodic reviews of those growth patterns may result in
bisecting *some* of those reserved blocks to make more space available
for similar assignments.

This can be shown to meet the requirements of individual LIRs to within
a few orders of magnitude of their long-term projections (pretty good),
and at the same time, optimize the packing efficiency, meaning the truly
free space will not be fragmented except to the degree absolutely necessary
for the existing assignments.

This means that new assignments have the largest possible potential prefix
size available, compared to other allocation methods. This can even be
demonstrated or possibly even proven mathematically, by modeling the
problem space.

> is enough to run a network of arbitrary size if you forego stateless

The same would be true of /80, which is what MAC-48 would result in, for
minimum prefix size for autoconf (and thus the standard end-user assignment
size).

Of the 16 bits reclaimed via this change, I would propose to the RIRs,
that 4 bits be added to initial allocations, 4 bits to reservations above
the initial allocations (for long-term growth), and the other 8 bits add
to the total space available for the RIRs to allocate to LIRs - by adjusting
the minimum and initial allocation sizes by 8 bits.

The numbers (4 bits and 8 bits) are not accidental - they are one nibble
in size, which matches up with the boundaries for reverse address lookups,
via ip6.arpa - which uses nibbles.

It seems to me, that while it would be an uphill battle, the main two issues
are transition and compatibity, and inertia (e.g. deployed code and
networks.)

The overall benefits to address space assignment, IMHO, outweigh that cost,
especially when considering the long-term health of the DFZ and the cost
to member organizations when having to do expensive upgrades to their
entire infrastructure to support bloat in the DFZ.

Brian

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 29 Aug 2007 18:09:48 +0200

> DFZ consisting of one PI block per LIR, has a problem fitting into the

(Please note the difference between the provider aggregatable (PA)  
blocks that are _allocated_ to LIRs/ISPs and the provider independent  
(PI) blocks that are _assigned_ to end-users (which may also be  
considered "LIRs" under the definition "LIR = anyone who pays the RIR  
fee".)

Simple problems have simple solutions: if your current block is not  
big enough, get a second block.

> is in fact the long-term requirement.

It's three bits: a /29 is reserved for each allocated /32. However,  
the problem with this approach is that a quick look at the IPv4  
routing table shows that the potential for aggregation created thusly  
isn't fully realized in practice. Reserving address space in this  
manner has two downsides:

- rapid fragmentation of relatively large amounts of address space
- increased potential for deaggregation because the maximum prefix  
length is often longer than the actual prefix length

Because of this, it's my opinion that the current practices are  
harmful and should be replaced by a new way of allocating, where all  
prefixes from a certain block have the same length, so it's possible  
to filter on this prefix length. The size of subsequent blocks is  
increased by a certain factor (I'm thinking 4 - 16) until an upper  
limit is reached beyond which the value of limiting the number of  
prefixes becomes lower than the downside of the potential address  
waste. For IPv4 this should probably be something like /12, for IPv6  
I'm thinking /24.

> long-term growth *potential*.

It's a waste of time and address space if the people don't aggregate,  
and IPv4 experience shows this doesn't happen as much as it should.

> minimum prefix size for autoconf (and thus the standard end-user  

I guess 48 bits is enough for all private networks, too, yes.

However, if we make this move now we can't make it in the future  
anymore, so we've wasted the additional 16 bits. If we keep things  
the way they are now this has the obvious advantage of not taking  
action over taking action, and it allows us to squeeze out 16 bits  
and still have autoconfig based on 48 bit identifiers at some point  
in the future. However...

> The overall benefits to address space assignment, IMHO, outweigh  

I disagree. It would be pretty hard to go from 64-bit autoconfig to  
48-bit autoconfig in a backward compatible way, because the global/ 
local bit that is very important here is in the upper 16 bits. It  
also kills efforts like CGA and HBA, where the interface identifier  
bits are used for crypto purposes. ~64 bits is already not very  
strong, ~48 would be too weak. Yes, we already have legacy  
considerations in IPv6.

> entire infrastructure to support bloat in the DFZ.

By adopting PI in IPv6, the community is saying that this isn't an  
issue.

Apart from that, what we need to control the DFZ under the current  
regime is the ability to make good prefix length filters. Currently,  
RIPE has says the maximum prefix length for 3 /8s is /29. This means  
that a filter that conforms to the RIPE policy will allow 6 million  
prefixes under full deaggregation. RIPE also gives out very large  
IPv6 blocks such as /19 and /20 from 2a01::/16 but also /32s. This  
means a filter must allow /32s so the holders of that /19 can  
fragment their block into 8192 /32s if they want. All the while, the  
utility of using a /19 over, say, 32 (or 28, or 25...) /24 for  
reasons of DFZ health is negilible because by the time 2000::/3 is  
filled up it's almost certainly possible for routers to handle 2^ 
(24-3) = 2 million prefixes. Giving out such large blocks only  
increases the potential for deaggregation while at the same time  
potentially wasting an awfully big number of addresses because the  
larger the block, the bigger the difference between the number of  
available addresses and the number of addresses actually used.

---

From: "TJ" <[email-masked]>
Date: Wed, 29 Aug 2007 15:00:55 -0400

IIRC - The 64 bit "host piece"/IID (or conversely, "only" a 64 bit routing
prefix) is a requirement only of the 2000::/3 address space, yes?
Presumably, if we come to the collective realization that this is a bad
policy, we will know this before we grow into the next (4000::/3?) space,
and revisit it then ... without breaking all of the then-current
networks/implementations ...  reasonable?

For my $.02 (or less) - yes, I think it is just a bit late to revisit the
whole "/64 or no /64" now ...
/TJ

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, August 29, 2007 11:18 AM
To: Iljitsch van Beijnum
Cc: Thomas Narten; IETF IPv6 Mailing List
Subject: Re: History of autoconfig RFCs and siblings, please?

Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 30 Aug 2007 08:20:53 +1200

Brian D,

You seem to be assuming that PI will be the dominant mode.
This seems very unlikely, since the vast majority of users
(i.e. SOHO) have no interest in what their IP address is and
no motivation to pay extra for PI. We have no possible
difficulty in supporting a few million PI prefixes in the
/48 or /56 world currently planned (apart from BGP4 blowing
up, of course, but that's being discussed elsewhere).

Regards
    Brian Carpenter

---

From: [email-masked]
Date: Wed, 29 Aug 2007 22:08:26 -0400 (EDT)

> You seem to be assuming that PI will be the dominant mode.

Not at all. I am assuming that prefixes in the DFZ won't be deaggregated
to any significant degree. All PA are aggregated, in theory at least,
under PI prefixes.

I am in fact only assuming PI prefixes as numerous as ASNs.
And that more multihoming for true "end-users" will be enabled by
the ability to have duplicative PA blocks big enough to cover end sites
N times over.

I am assuming that the *vast* majority of networks will have PA native,
or ULA-* native and 1:1 NAT onto PA, or "unannounced" PI internally
with 1:1 NAT facing multiple upstream PA blocks.

> no motivation to pay extra for PI.

(I don't disagree on the latter, making this moot. And you mis-speak
for me on what I assume.)

> We have no possible

I disagree strongly.

Yes, I'm aware, and I'm participating in those discussions.

The size of the autoconf prefix is out of scope for *those* venues.

However, it *directly* impacts assignments in those areas.

Which is why I raised the question, here.

Whether autoconf uses /64 or /68 or /80, has direct implications on
the minimum prefix assignable to an end-user should be, and what the
typical minimum minimum PI block size should be.

A "few million" PI prefixes is not actually something we should plan for,
even if it fits into the range of space between /3 and /32 (as in,
2000::/3, and /32 LIR PI assignments.)

Here's why:

On the biggest iron currently deployed in most networks, the size
of the DFZ in IPv6 that can *reasonably* supported has an upper bound
dictated by deployed TCAM size and per-prefix TCAM allocation needed.

These days, for example, on an IPv6-*only* Cisco 7600 with 3BXL, will
only hold a theoretical maximum of 119,000 prefixes. Bigger iron may
support double that, but again, only as IPv6-ONLY. When you add IPv4
onto the same platform, the huge IPv4 DFZ  eats most of the capacity
for IPv6 prefixes. Most providers will need to have dual-stack for
a considerable period of time (3-5 years minimum, IMHO.)

And on that basis, how many end-user assignments fit into PI prefixes
which are sized sufficiently to grow vertically inside reserved space,
rather than multiply and bloat the DFZ, is very important.

Too big an end assignment, and it results in a squeeze play, where either
too few PI blocks can be reserved to go around (fairly), or too many small
PI blocks end up being used.

Adding 16 more bits to the range between PI block size and end-user
assignment prefix length, and the squeeze effect is relaxed considerably.

Making really big assignments (say /20 to /42) to handle end-assignments
of /80, gives a much longer life span to each PI block, and keeps the
PI per ASN down to a nice low value of "1".

Brian Dickson

---

From: Mark Smith <[email-masked]>
Date: Thu, 30 Aug 2007 19:29:59 +0930

<snip>
> a considerable period of time (3-5 years minimum, IMHO.)

I'm inclined to believe that dual-stack provider networks are going to
be relatively rare, and may not exist at all. I think it'll either be
IPv6 over MPLS (in one way or another e.g. 6PE or native IPv6 over
MPLS), or Softwires, where IPv6 is encapsulated inside IPv4 (or
vise-versa) at the edges, and tunnelled across a native IPv4 or IPv6
backbone to the egress device. I think softwires is also likely to be
the better alternative for enterprise networks as well, although the
parallel introduction of IPv6 and BGP may initially be a bit
intimidating for them. Assuming a Softwires IPv4 over a native IPv6
network, one method of avoiding having to implement BGP could be to
encode IPv4 prefix information below a reserved IPv6 prefix, and then
have the normal IPv6 IGP carry that information between the egress and
ingress nodes.

Both of these techniques push the "heavy lifting" of matching a
destination layer 3 addresses against many and specific prefixes to the
edge of the network. Once the problem can be pushed to the edge of the
network, it can typically be scaled more easily. The TCAM limit in
your high end internal devices then becomes a limit on how many
forwarding devices you have in your network, not how many prefixes the
network can forward for.

Regards,
Mark.

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Fri, 31 Aug 2007 00:09:59 +0900 (JST)

> be relatively rare, and may not exist at all. I think it'll either be

	WIDE and two of the biggest japanese ISPs are already dual-stacked,
	and if my guess is right it has been so for more than 5 years.
	it is not economical to purchase separate trans-pafici circuit.

itojun

---

From: Scott Leibrand <[email-masked]>
Date: Thu, 30 Aug 2007 08:27:23 -0700

> 	it is not economical to purchase separate trans-pafici circuit.

Itojun,

I believe he was referring to the *method* of supporting both IPv4 and 
IPv6, and arguing that core routers will tend to be addressed with 
either IPv4 or IPv6, but not both.  Instead, support for the second 
protocol will tend to be provided by edge routers tunneling across the 
core (using 6PE, softwires, or another method), rather than by native IP 
forwarding by core routers.  These solutions don't require separate 
circuits for IPv6 and IPv4 traffic.

Are you familiar enough with the internal addressing of those Japanese 
ISPs to say whether they address their core routers with both IPv6 and IPv4?

Another consideration is how big a given network's "core" is.  In the 
case of a geographically constrained network, it may be quite small, and 
a dual-stack core may make more sense than MPLS.  For large global 
networks, however, it appears to me that tunneling across the core is 
becoming the preferred mode of operation.

-Scott

---

From: <[email-masked]>
Date: Thu, 30 Aug 2007 16:58:33 +0100

> 	it is not economical to purchase separate trans-pafici circuit.

6PE over MPLS and v6 tunnels over Softwires do not require purchasing
separate circuits.

--Michael Dillon

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 31 Aug 2007 08:12:12 +1200

Just to be clear about what I meant here: I don't
believe we know *today* how to make BGP4 handle
millions of PI prefixes; but even if that is possible
some time in the future, we still have to assume that
the vast majority (billions) of end users are in PA space
for ever.

    Brian

---

From: Mark Smith <[email-masked]>
Date: Fri, 31 Aug 2007 06:58:21 +0930

On Thu, 30 Aug 2007 08:27:23 -0700

> > 	it is not economical to purchase separate trans-pafici circuit.

Oh ok. Down here in .au our perspective on things like IPv6 deployment
tends to get warped by being an English speaking country. I know Japan
has IPv6 quite widely deployed, however we rarely if ever see any
English news about it.

> circuits for IPv6 and IPv4 traffic.

That's what I was trying to say. It seems to me that the relative
simplicity of a single core forwarding protocol and more general
purpose characteristics (of MPLS, GRE or L2TP) of these "edge-to-edge
tunnelling methods" might to be more appealing than dual-stack for
those who haven't already deployed dual-stack, in particular if they're
facing a hardware or software upgrade cycle to get there.

Regards,
Mark.

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Fri, 31 Aug 2007 08:43:14 +0900 (JST)

(sorry if it gets a duplicate)

> be relatively rare, and may not exist at all. I think it'll either be

	WIDE (AS2500) and two of the major ISPs which deploy IPv6 are running
	dual-stack.  i bet others too (Verio, Internet2, anyone?)
	it is not economical to run two separate physical link across the
	pacific ocean.

itojun

---

From: Mark Andrews <[email-masked]>
Date: Fri, 31 Aug 2007 10:37:57 +1000

> 	it is not economical to run two separate physical link across the

	HE is according to their web pages.

---

From: Stig Venaas <[email-masked]>
Date: Fri, 31 Aug 2007 03:51:24 +0200

> 	it is not economical to run two separate physical link across the

At least pretty much all the academic networks I know are dual-stack,
pretty big networks too, and this happened years ago.

Several years ago the operator I work for also did that. We run IS-IS
which handles both protocols with just one routing instance which is
nice. The only problem we have is that it is hard to know exactly how
much and what IPv6 traffic passes through the core. E.g. even though
the routers are Netflow v9 capable, the hardware is not capable of
creating IPv6 flow info.

Stig