Ddocument: draft-ietf-dna-goals-03.txt Review: Spencer Dawkins Date: 29 november 2004 Summary for publication as Informational: This draft is on the right track for publication as Informational. It's a well-written discussion of a difficult topic area. I provided a bunch of questions and editorial suggestions, but had only one "concern", in Section 3. Note that Gen-ART comments aren't binding, per se, unless an AD likes them enough to stick them in the ID tracker :-) But I hope you find them helpful, and not too late in the process. Have a great week, Spencer ------------------------- 1. Introduction When a host has established a new link-layer connection, it can send and receive some IPv6 packets at the link, particularly those used for configuration. On the other hand, the host has full Internet connectivity only when it is able to exchange packets with arbitrary destinations. Spencer - question - I think I know what you're getting at here, but "full Internet connectivity" seems more ambitious than it needs to be - isn't the goal "exchanging packets with off-link destinations"? I know we're ignoring IPv6 NATs, but this seems to overlook firewalls, etc. When a link-layer connection is established or re-established, the host may not know whether its existing IP configuration is still valid for Internet connectivity. A subnet change might have occurred when the host changed its attachment point. Spencer - editorial - "subnet" isn't defined until later in the document. In practice, the host doesn't know which of its addresses are valid Spencer - editorial - "knows neither if" seems awkward - "doesn't know whether"? on the newly attached link. The host knows neither if its existing default router is on this link, nor whether its neighbor cache entries are valid. Correct configuration of each of these components are necessary in order to send packets on and off the link. To examine the status of the existing configuration, a host may check whether a 'link change' has occurred. The term 'link' used in this document is as defined in RFC 2461 [1]. The notion 'link' is not identical with the notion 'subnet' as defined in RFC 3753 [3]. For example, there may be more than one subnets on a link and a host Spencer - editorial - "more than one subnet on a link" connected to a link may be part of one or more of the subnets on the link. Today, a link change necessitates an IP configuration change. Whenever a host detects that it has remained at the same link, it can usually assume its IP configuration is still valid. Otherwise, the Spencer - question - why "usually" here? existing one is no longer valid and a new configuration must be acquired. Hence, to examine the validity of an IP configuration, all that is required is that the host checks for link change. This draft considers the DNA procedure only from the IPv6 point of view, unless otherwise explicitly mentioned. Hence, the term "IP" is to be understood to denote IPv6, by default. For the IPv4 case, refer [10]. Spencer - editorial - "refer to [10]" 2. Problems in Detecting Network Attachment There are a number of issues that make DNA complicated. First, wireless connectivity is not as clear-cut as wired one. Second, it's Spencer - question - don't understand what "clear-cut" means here. Are you saying that wireless connectivity is less robust? less consistent? Is there a missing verb ("DETECTING wireless connectivity is not as clear-cut as detecting wireline connectivity"?) Spencer - editorial - "as wired connectivity" difficult for a single RA message to indicate a link change. Third, Spencer - editorial - spell out "Router Advertisement" (first usage in the document). Router Discovery may take too long and result in service disruption. 2.3 Delays The following issues cause DNA delay that may result in communication disruption. 1) Delay for receiving a hint Hint is an indication that a link change might have occurred. This hint itself doesn't confirm a link change, but initiates appropriate DNA procedures to detect the identity of the currently attached link. Hints come in various forms, and differ in how they indicate a possible link change. They can be link-layer event notifications [9], the lack of RA from the default router, or the receipt of a new RA. The time taken to receive a hint also varies. Spencer - question - I thought that you were saying previously that "receipt of a new RA" was potentially ambiguous. This doesn't make "receipt of a new RA" sound quite as ambiguous to me. Periodic RA beaconing transmits packets within an interval varying randomly between MinRtrAdvInterval to MaxRtrAdvInterval seconds. Because a network attachment is unrelated to the advertisement time on the new link, hosts are expected to arrive, on average, half way through the interval. This is approximately 1.75 seconds with Neighbor Discovery [1] advertisement rates. Spencer - question - does 1.75 seconds match your expectations for how quickly DNA can be initiated elsewhere in the paper? This question also includes the 1+0.5 maximum delay in seconds included in 2)... 2) Random delay execution for RS/ RA exchange Router Solicitation and Router Advertisement messages are used for Router Discovery. According to [1], it is sometimes necessary for a host to wait a random amount of time before it may send an RS, and for a router to wait before it may reply with an RA. Before a host sends an initial solicitation, it SHOULD delay the transmission for a random amount of time between 0 and MAX_RTR_SOLICITATION_DELAY (1 second). Furthermore, any Router Advertisement sent in response to a Router Solicitation MUST be delayed by a random time between 0 and MAX_RA_DELAY_TIME (0.5 seconds). 3. Goals for Detecting Network Attachment The DNA working group has been chartered to define an improved scheme for detecting IPv6 network attachment. In this section, we define the goals that any such solutions should aim to fulfil. DNA solutions should correctly determine whether a link change has occurred. Additionally, they should be sufficiently fast so that there would be no or at most minimal service disruption. They should neither flood the link with related signaling nor introduce new security holes. Spencer - concern - is this high-level "should be sufficiently fast" consistent with the 1.5-2-second delays described in section 2 of this document? I guess I'm asking, is interactive voice clearly in scope/out of scope? When defining new solutions, it is necessary to investigate the usage of available tools, NS/NA messages, RS/RA messages, link-layer event notifications [9], and other features. This will allow precise description of procedures for efficient DNA Schemes. Spencer - editorial - NS/NA haven't been spelled out yet. 3.1 Goals list G1 DNA schemes should detect the identity of the currently attached link to ascertain the validity of the existing IP configuration. They should recognize and determine whether a link change has occurred and initiate the process of acquiring a new configuration if necessary. G2 When upper-layer protocol sessions are being supported, DNA schemes should detect the identity of an attached link with minimal latency lest there should be service disruption. Spencer - editorial - (at least, I hope it's editorial) This goal seems to say that DNA will behave differently "when upper-layer protocol sessions are being supported" - is that what's intended? If it is actually what's intended - at the very least, some definition of "upper-layer protocol sessions" should be provided. G3 In the case where a host has not changed a link, DNA schemes should not falsely assume a link change and an IP configuration change should not occur. Spencer - question - so, the goal is NO false positives, with no qualification? G4 DNA schemes should not cause undue signaling on a link. G5 DNA schemes should make use of existing signaling mechanisms where available. G6 DNA schemes should make use of signaling within the link (particularly link-local scope messages), since communication off-link may not be achievable in the case of a link change. G7 DNA schemes should be compatible with security schemes such as Secure Neighbour Discovery [4]. G8 DNA schemes should not introduce new security vulnerabilities. The node supporting DNA schemes should not expose itself or others on a link to additional man in the middle, identity revealing, or Spencer - editorial - "identity revealing" doesn't sound quite right here (but don't have alternate text). denial of service attacks. G9 The nodes, such as routers or hosts, supporting DNA schemes should work appropriately with unmodified nodes, such as routers or hosts, which do not support DNA schemes. G10 Hosts, especially in wireless environments, may perceive routers reachable on different links. DNA schemes should take into consideration the case where a host is attached to more than one link at the same time.