David, No problem, you're welcome. I will talk with my co-authors in Erik and Wes and see what we can do. To us it's obvious that ND is a link-local scoped protocol and of course, if a receiver sees an ND message that is not present in the receiver's on-link prefixes, the receiver has to drop the ND message. That is what Erik said too in v6ops on 25th June 2008. Sorry, at the time I wasn't subscribed to v6ops and saw your thread a day or two later. Otherwise I would have said the same.
Kind Regards. Hemant -----Original Message----- From: MILES DAVID [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 02, 2008 8:23 PM To: Hemant Singh (shemant); Wes Beebee (wbeebee); ipv6@ietf.org Cc: Thomas Narten; [EMAIL PROTECTED] Subject: RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt Hemant, Thanks for your patience. Given we are now very clear that a receiver should drop any ND message from a source that it is not in its prefix list, might I suggest the paragraph in question be amended to say: In addition to the Prefix List, individual addresses are on-link if they are the target of a Redirect Message indicating on-link. Removing the text: or the source of a valid Neighbor Solicitation or Neighbor Advertisement message. The clarification would be a step in the right direction. My 2c, and yes - this is now closed. -David -----Original Message----- From: Hemant Singh (shemant) [mailto:[EMAIL PROTECTED] Sent: Wednesday, 2 July 2008 12:44 AM To: MILES DAVID; Wes Beebee (wbeebee); ipv6@ietf.org Cc: Thomas Narten; [EMAIL PROTECTED] Subject: RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt David, Please see in line below between "<hs>" and "</hs>". -----Original Message----- From: MILES DAVID [mailto:[EMAIL PROTECTED] Sent: Monday, June 30, 2008 8:24 PM To: Hemant Singh (shemant); Wes Beebee (wbeebee); ipv6@ietf.org Cc: Thomas Narten; [EMAIL PROTECTED] Subject: RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt Thanks Hemant and Wes, To your question on examples - this came about as a result of customer interpretation of RFC 4861 (and a specific test case). <hs> May we know more about this customer test cases? Is your host to host example also something that your customer is testing? If yes, what OS are the hosts running and why are hosts not behaving correctly for basic source address selection? Further if your customer is testing router to router ND, what router is being used and what is firmware version on the router? You see, in IETF such details need to be open to nail down any discussion. Anyhow, for the router to router example you gave, Thomas Narten and Erik have already closed that issue saying no harm is caused because the bogus ND-cache entry is not used. We closed the host to host example in our earlier email saying the forwarding table on the host will take precedence over ND-cache - just like the router to router ND example. </hs> The RFC literally says one should populate Neighbour Cache when you receive a NS regardless of whether that address is in the Prefix List and any NA/ND received is on-link. This process in RFC 4861 does not describe how on-link determination is affected so I hoped we can have this discussion to conclude whether the text should remain or whether we need to clarify on-link determination. The examples you have used (no router with manual/DHCPv6 assigned addresses) are much better. My query relates to text in both RFC4861 and your draft, where we say that any ND received means the address is considered on-link. In your draft you explicitly state (in point 5) that if there are no Default Routers, and no other information indicating on-link prefix (including the mere presence of an address) then (sub-point 2): "The host MUST NOT perform address resolution for non-link-local addresses". This would seem to create a stalemate situation. I.e., for any received ND a host will consider that address on-link (bullet point in question in RFC4861), but you MUST NOT perform address resolution unless a destination address is on-link (your draft section 5.2) and so cannot populate other hosts with your addresses by sending NS. <hs> Not quite. Bullet 5 from section 2 of our draft is derived from RFC4943. Please read section 4 of RFC4943 that said on-link assumption is harmful. Our bullet is totally correct to say, once it has been determined that an address or prefix is not on-link, then of course, the address or prefix is off-link. If an address or prefix is off-link, then, of course, an interface cannot issue an NS to resolve any non-link-local destination. There is no stalemate because only if no on-link determination could be made on an address or prefix, does the node goes into recommended procedure of RFC4943 to send an ICMP Destination Unreachable. Of course, if an on-link determination has been made because if an NS was received at the interface in a router-less network, and prefix length is configured on the interface's configured IPv6 address, the recommended operation of RFC4943 will not take place. </hs> NA are not periodically sent and a receiving host should discard them if the target does not match a valid interface (RFC 4861 7.2.5). Per your email, the intent is clearly for the receipt of a ND to update on-link determination (this ::/128 is now on-link). We must also ensure we will send ND for this on-link address to update other hosts. As want the reception of a ND to indicate that address (the target/source of a NA, and the source of a NS) is on-link we need some clarifying text that would describe: - How on-link determination is enhanced with information from ND messages received - That we shouldn't discard NA with a target that isn't in the receiving host's Neighbour Cache - we need to somehow update on-link determination with information from the NA - Whether we update Prefix List with ::/128 from the received ND messages; consult Neighbour Cache for on-link determination; create an entry in the Destination Cache, etc - Determine how long an address will be considered on-link for. What lifetime will we associate with this learnt on-link address? Until interface reset/reinitialise or receipt of a PIO? What if a default router becomes active - should we still treat this ::/128 (from a received ND) on-link? - How a hostA will send NA/ND to other hosts so they may determine hostA's address is on-link <hs>I, Wes, Erik, and Thomas have already made is clear that routing table on a router or data forwarding table on a host takes precedence over any ND-cache entry. Further, any change in drafts or RFC's are made if any severe problem is found for tens of millions of nodes. We haven't see such a problem in your router-less host example. It makes sense to consider your alternatives below. </hs> The other alternatives are to: - Require a prefix-len be specified when manually configuring an address (ie, adopt SLAAC rules) <hs> Our draft already covers such a thought. Please see bullet 2 of section 2 in our draft. One sentence in the bullet says: [Note that this requirement for manually configured addresses is not explicitly mentioned in [RFC4861].]. We highlighted manual configuration in our draft. After that, it is clear as daylight that on-link determination for a prefix cannot be made unless a prefix length is also available with the prefix in manual configuration. I think bullet 2 should suffice for this alternative suggestion by you. </hs> - Add prefix-len to DHCPv6 IA_NA/TA Options to support environments without routers (only used when there is no RA received) <hs> Please read emails from me in 6man archives where I have clearly said, I will never agree to adding prefix len as a DHCPv6 option. My reasons are clear in the emails archived. When I get the time, I can forward some emails privately to you. But, please let's not gate this draft waiting for those emails. I hope we can get closure with this email. </hs> Thanks. Hemant - Mandate the requirement for RA to support any IPv6 address other than link-local Best Regards, -David Miles -----Original Message----- From: Hemant Singh (shemant) [mailto:[EMAIL PROTECTED] Sent: Tuesday, 1 July 2008 12:37 AM To: MILES DAVID; Wes Beebee (wbeebee); Wojciech Dec (wdec); Brian Haberman; ipv6@ietf.org Cc: Bob Hinden Subject: RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt David, We will explain where we think RFC4861 came from with the 4th bullet in on-link definition in Terminology section of RFC4861. We will explain why that bullet is needed and why the bullet does not change. Further, we don't understand where you are going with these contrived examples? It's a stretch already being in a router-less network and contriving examples that clearly have source-address selection problems. In the routerA to routerB contrived example, the example included routes between A and B. We have said routing table takes precedence over ND cache in that example. For the host to host case below, since IPv6 addresses have been configured on the hosts with a prefix length, each host has an entry in data forwarding table for the prefix derived from host IPv6 address configuration. IPv6 data forwarding tables on the host will take precedence in the same way as in your router example. Anyhow, here is the justification for the 4th bullet in RFC 4861 which is what statements in our draft derive from. In a router-less network, a node's network interface may be configured using manual configuration or DHCPv6. Note DHCPv6 does not dole out prefix length without which, just given an IPv6 address from DHCPv6, a DHCPv6 client cannot make an on-link determination for any prefix. Likewise, manual configuration may not configure a prefix length when an IPv6 address is configured on the interface - in this case, the node still does not have any means to determine what prefix is on-link. Thus far, any host in this network has not been able to determine if any prefix is on-link. Only if the host is able to determine any prefix is on-link, can the host in such a network send data. There in comes the rule in 4th bullet from the definition of on-link from RFC4861 that applies to this network - any Neighbor Discovery message is received from the address. Hemant & Wes -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of MILES DAVID Sent: Thursday, June 26, 2008 8:57 PM To: Wes Beebee (wbeebee); Wojciech Dec (wdec); Brian Haberman; ipv6@ietf.org Cc: Bob Hinden Subject: RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt Wes & Hemant, Can we walk through the situation of hosts without routers where you suggest a possible issue? HostA ----(link)---- HostB HostA: 2002:db8:100::1234/64 2002:db8:200::1234/64 HostB: 2002:db8:100::9999/64 Are we suggesting HostA may src from 2002:db8:200::1234 to 2002:db8:100::9999, ie, we are forgoing source-address selection and are overriding this behaviour? Assuming that is the case, and assuming HostB did in fact populate a Neighbour Cache entry with 2002:db8:200::1234 - STALE, I cannot see how this would affect HostB's next-hop/on-link determination. According to the current text in RFC4861 HostB would perform the following on the first packet to send to 2002:db8:200::1234: 1) Check destination cache (empty, never seen this destination before) 2) Check Prefix List for on-link determination (off-link) - 2002:db8:200::1234 is not in the Prefix List 3) If off-link, select a router from Default Router List and determine next-hop IP (no default routers) --end in our example as there are no routers-- 4) Consult Neighbour Cache for link-layer address of next-hop, invoke Address Resolution if needed 5) Cache result in destination cache I understand Neighbour Cache is not consulted for next-hop/on-link determination, and Destination Cache is updated with the result of the Prefix-List lookup (next-hop determination). So while there is a STALE entry in the Neighbour Cache, it is never queried. Similar to the case of a router, I think we would need to update a host's equivalent (the Prefix List) to affect forwarding. It would be good to better understand the scenario you are seeing between host and host. Best Regards, -David -----Original Message----- From: Wes Beebee (wbeebee) [mailto:[EMAIL PROTECTED] Sent: Friday, 27 June 2008 12:29 AM To: Wojciech Dec (wdec); Brian Haberman; ipv6@ietf.org Cc: MILES DAVID; Bob Hinden Subject: RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt This rule derives directly from the Terminology section of RFC 4861 (definition of on-link). Note that the presence of a bogus entry causes no harm (the routing table takes precedence over the ND cache in this case). However, the removal of the rule DOES cause harm in the case of communication without routers. Therefore, we currently see no reason to change the text. - Wes & Hemant -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Wojciech Dec (wdec) Sent: Thursday, June 26, 2008 10:05 AM To: Brian Haberman; ipv6@ietf.org Cc: MILES DAVID; Bob Hinden Subject: RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt Based on a recent thread (http://www.ops.ietf.org/lists/v6ops/v6ops.2008/msg00896.html) the following paragraph from the draft appears to warrant some more thought if not outright a revision " In addition to the Prefix List, individual addresses are on-link if they are the target of a Redirect Message indicating on-link, or the source of a valid Neighbor Solicitation or Neighbor Advertisement message. Note that Redirect Messages can also indicate an address is off-link. Individual address entries can be expired by the Neighbor Unreachability Detection mechanism." Using unconditionally the source address of a neighbour solicitation or NA to determine on-link would indeed appear to be undesirable, unless the intent is allow some direct host-host cross subnet/prefix communication without a router involved at any stage (this is not a good idea IMO). A constraint could be introduced such as: A host only learns on-link addresses from the source of NS and NA messages iff it already has an on-link prefix that would cover that address. Learning from Redirect messages would continue to be allowed. My 2c. -Woj. > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > Of Brian Haberman > Sent: 26 June 2008 14:17 > To: ipv6@ietf.org > Cc: Bob Hinden > Subject: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt > > All, > This message starts a 3-week 6MAN Working Group Last Call on > advancing: > > Title : IPv6 Subnet Model: the Relationship between > Links and Subnet Prefixes > Author(s) : H. Singh, et al. > Filename : draft-ietf-6man-ipv6-subnet-model-00.txt > Pages : 8 > Date : 2008-05-08 > > as a Proposed Standard. Substantive comments and statements of > support for advancing this document should be directed to the mailing > list. > Editorial suggestions can be sent to the document editor. > This last call will end on July 10, 2008. > > Regards, > Brian & Bob > 6MAN co-chairs > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------