On Thu, Aug 16, 2007 at 08:53:10AM -0400, James Carlson wrote: > I don't see how the server could possibly construct a valid Reply > 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. > 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), 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. > 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. 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. -- 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
pgpod4XGCpY4s.pgp
Description: PGP signature
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
