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 PROTECTED] Sent: Friday, August 10, 2007 7:39 PM To: Leino, Tammy; Iljitsch van Beijnum Cc: ipv6@ietf.org; John Jason Brzozowski (JJMB); [EMAIL PROTECTED] Subject: RE: prefix length determination for DHCPv6 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 PROTECTED] Sent: Friday, August 10, 2007 7:28 PM To: Bernie Volz (volz); Iljitsch van Beijnum Cc: ipv6@ietf.org; John Jason Brzozowski (JJMB); [EMAIL PROTECTED] Subject: RE: prefix length determination for DHCPv6 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). "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." >>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? 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 PROTECTED] Sent: Friday, August 10, 2007 7:20 PM To: Leino, Tammy; Iljitsch van Beijnum Cc: ipv6@ietf.org; John Jason Brzozowski (JJMB); [EMAIL PROTECTED] Subject: RE: prefix length determination for DHCPv6 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 PROTECTED] Sent: Friday, August 10, 2007 7:10 PM To: Iljitsch van Beijnum Cc: ipv6@ietf.org; John Jason Brzozowski (JJMB) Subject: RE: prefix length determination for DHCPv6 Thank you very much for your comments. Regarding your comment: >> 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. 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." >> (There is of course the consideration that at this time, very few IPv6 implementations can configure an address through DHCPv6.) 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. >> 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: 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 -----Original Message----- From: Iljitsch van Beijnum [mailto:[EMAIL PROTECTED] Sent: Friday, August 10, 2007 6:52 PM To: Leino, Tammy Cc: John Jason Brzozowski (JJMB); Hemant Singh (shemant); ipv6@ietf.org Subject: Re: prefix length determination for DHCPv6 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. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
