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. >Not a thing until someone is going to start USING DHCPv6 address 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 PROTECTED] Sent: Thursday, August 16, 2007 7:08 PM To: Hemant Singh (shemant) Cc: JINMEI Tatuya / ????; David W. Hankins; [EMAIL PROTECTED]; [email protected] Subject: Re: [dhcwg] Re: prefix length determination for DHCPv6 On 17-aug-2007, at 0:51, Hemant Singh (shemant) wrote: > 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? (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". > 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. > 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? Not a thing until someone is going to start USING DHCPv6 address assignment, I'd say. -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
