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 PROTECTED] Sent: Friday, August 17, 2007 4:09 PM To: IETF IPv6 Mailing List; [EMAIL PROTECTED] Subject: Re: [dhcwg] Re: prefix length determination for DHCPv6 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? -- james woodyatt <[EMAIL PROTECTED]> member of technical staff, communications engineering _______________________________________________ dhcwg mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/dhcwg -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
