This page contains information on Detection of Network Attachment (DNA) for IPv4, including current status of the specification.
Document status
The DNAv4 specification has been published as RFC 4436. There is one confirmed errata.
Related work in the IETF DHC WG
DHC WG
Charter
DHC
Mailing List Archives
Related work in the IETF DNA WG
DNA WG
Charter
DNA
Mailing List Archives
Related work in IETF ZEROCONF WG
ZEROCONF WG
Charter
ZEROCONF WG Issues
List
ZEROCONF WG
Archives
IPv4 Linklocal addressing specification
Open Issues List
A description in red implies that no issue has been submitted (if you are the owner of such a message, please send the editor an issue).
An asterix following an Issue number (e.g. Issue #666*) means that the issue entry is not up to date, and the author is expect to send additional text to the editor.
To submit a new issue, send an e-mail to the DHC WG Mailing list, using the following template. Please CC: the editor.
Description of issue
Submitter name: Your_Name_Here
Submitter email address: Your_Email_Address_Here
Date first submitted: Insert_Date_Here
Reference: URL to e-mail describing problem, if available
Document: DNA-<version>
Comment type: ['T'echnical | 'E'ditorial]
Priority: ['S' Must fix | '1' Should fix | '2' May fix ]
Section: Insert_Section_Number_Here
Rationale/Explanation of issue:
Length description of problem
Requested change:
Proposal
For open issues, the following values are used in the Status Field:
Text Proposed - Text has been proposed on the list, and no consensus has been reached
Accepted - Text has been proposed, consensus has been reached, but the fix hasn't been included in a specification yet.
Pending - Discussion is on-going, no proposed text has been proposed
No Discussion - No discussion has been initiated on this issue.
Clarifying Text Required - The issue can be closed if additional clarifying text is added to the draft
Possible Reject - Issue will be rejected unless objections occur.
| DNAv4 Open Issues
Issue Number |
Status | Type | Description | Owner |
| Issue 41 | RFC4436-Errata | Editorial | Typo | Bernard Aboba |
Resolved Issues List
The following table contains the issues that have already been resolved, and the fix included in a revision of the specification.
The following are the long form versions of the issues:
Issue 1: No security considerations
section
Submitter: Bernard Aboba
Submitter email address:
aboba@internaut.com
Date first submitted: August 1, 2003
Reference:
Document: DNAv4-00
Comment type: T
Priority: S
Section:
4
Rationale/Explanation of issue:
This document has no Security Considerations section. Surely there must be security issues?
Please add the following:
"4. Security Considerations
Detection of Network Attachment (DNA) is
typically insecure, so that it
is inadvisable for a host to adjust its
security based on which network
it believes it is attached to. For example,
it would be inappropriate
for a host to disable its personal firewall based
on the believe that it
had connected to a home network.
ARP [RFC826]
traffic is inherently insecure, so that the reachability
test described in
Section 1.3 can be easily spoofed by an attacker,
leading a host to conclude
that it remained attached to a former
network. Similarly, where DHCP
[RFC2131] traffic is not secured, an
attacker could masquerade as a DHCP
server, in order to convince the
host that it was attached to a particular
network.
Where secure detection of network attachment is required, a host
MAY
wish to skip the ARP-based reachability test entirely since it cannot
be
secured, and go immediately to the IPv4 address acquisition
phase,
utilizing authenticated DHCP [RFC3118]."
Proposed resolution: Accept
Issue 2: No IANA considerations
section
Submitter: Bernard Aboba
Submitter email address:
aboba@internaut.com
Date first submitted: August 1, 2003
Reference:
Document: DNAv4-00
Comment type: T
Priority: S
Section:
3
Rationale/Explanation of issue:
This document has no IANA Considerations section. Please insert the following:
"3. IANA Considerations
This specification does not request the
creation of any new parameter
registries, not does it require any other IANA
assignments."
Proposed resolution: Accept
Issue 3: No Requirements Section
Submitter:
Bernard Aboba
Submitter email address: aboba@internaut.com
Date first
submitted: August 1, 2003
Reference:
Document: DNAv4-00
Comment type:
T
Priority: S
Section: 1.1
Rationale/Explanation of issue:
This document has no citation to RFC 2119. Please add the following:
"1.1. Requirements
In this document, several words are used to signify
the requirements of
the specification. These words are often capitalized. The
key words
"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD
NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to
be
interpreted as described in [RFC2119]."
Proposed resolution: Accept
Issue 4: No Terminology Section
Submitter:
Bernard Aboba
Submitter email address: aboba@internaut.com
Date first
submitted: August 1, 2003
Reference:
Document: DNAv4-00
Comment type:
T
Priority: S
Section: 1.2
Rationale/Explanation of issue:
This document has no terminology section. Please add the following:
"1.2. Terminology
This document uses the following terms:
DHCP
client A DHCP client or "client" is an Internet host using DHCP
to obtain
configuration parameters such as a network
address.
DHCP server A DHCP
server or "server" is an Internet host that
returns configuration parameters
to DHCP clients.
Routable address
In this specification, the term
"routable address" refers
to any address other than an IPv4 Link-Local
address.
This includes private addresses as specified in
[RFC1918]."
Proposed resolution: Accept
Issue 5: IPv4LL -> DHCP
transition
Submitter: Robert Elz
Submitter email address: kre@munnari.OZ.AU
Date first submitted:
September 10, 2003
Reference: http://www1.ietf.org/mail-archive/working-groups/dhcwg/current/msg02331.html
Document:
DNAv4-01
Comment
type: T
Priority: S
Section: 2.3
Rationale/Explanation of issue:
I certainly agree that the long waits that dhcp clients usually
fall into
after their initial few attempts to contact a dhcp
server can be most
annoying, and that retrying more often would
be nicer from the end user's
viewpoint.
On the other hand, I'm not sure that I'd be happy to have a
LAN
with perhaps hundreds of hosts (maybe thousands) all
sending
continuous streams of broadcast packets looking for a DHCP
server.
(A thousand hosts, with a 25 second (avg) delay is 40
broadcast
packets a second, which is starting to get too high - make
that
5000 hosts, which is not unreasonable in some switched
environments,
and you're at 200 broadcast packets a second - which is
beyond
inconvenient and into extremely annoying).
It may be that the
correct strategy here is for hosts that have
failed to contact the DHCP
server [and allocated an IPv4LL address is] to
remain on a "slow retry"
regime, but always set the "broadcast reply" bit
in dhcp
requests.
Then, upon noticing a DHCP reply, hosts could (after a short
random
delay to avoid a packet deluge) try again to get an address (no
requirement
to request a broadcast reply, if not needed, after seeing one) -
the
observed reply would indicate that the DHCP server has returned to
life.
If there are just a few hosts that aren't getting replies,
perhaps
because the DHCP server is ignoring them deliberately, having
them
set the broadcast reply request bit (unnecessarily) will be
harmless,
there won't be replies.
If the DHCP server has really gone
absent, and there are lots of people
looking for replies, this would allow
the hosts to avoid sending much
traffic until there is evidence that there's
a reasonable chance of
achieving a result.
Ideally, the slow down rate
would depend upon the number of clients
around to make requests (what is
really wanted is one client at random
making a request every few seconds, and
all the others staying quiet until
they observe a reply) but with DHCP,
knowing how many other clients there
are would mean listening to request
packets, that clients don't usually
want to do (and on some OS's is hard,
without precluding the client from
also being a server on a different
LAN). So, probably there just needs
to be a reasonable compromise
rate set.
But this is all DHCP, not LL addressing, and needs the DHCP
experts
to give advice on - it is possible that they have considered,
and
rejected, this kind of approach in the past.
[Ted Lemon]
I think the right answer to this question is to simply decouple the IPv4LL
and DHCP state machines. As long as the IPV4ll state machine can
reach out
and touch the DHCP state machine, it's likely to do things that
break the
operation of the DHCP state machine.
So the right answer
is, IMHO, that if the IPv4LL believes that it *may* be in
a state where
connectivity has been lost, it should configure itself a
link-local address,
and when it leaves that state, it should make the
transition back to using
the globally routable address exclusively.
In other words, the IPv4LL
state machine should watch the DHCP state machine
and make decisions at
least in part based on what state the DHCP client is
in, but the DHCP client
should not change its behavior at all to accomodate
this. So if
the DHCP client is in the INIT-REBOOT state and doesn't get an
answer from
the DHCP server, it should continue using its globally routable
address. But the IPv4LL agent should make note of this, and
configure an
IPv4LL address.
To be clear, I meant here "decouple the DHCP state machine from the IPv4ll
state machine," but not "decouple the IPv4LL state machine from the DHCP
state machine" - obviously this isn't possible if we do what I've
proposed.
Does that make sense? I realize that this has the
downside that now the
IPv4LL agent must be able to watch the DHCP client in
order to do a good job
of maintaining Iv4LL service, but I think this is
preferable to breaking DHCP
service.
Now we are being asked to put a bandaid on this by making it *re-acquire*
an address quickly. So the root of the problem is, in fact, that
the DHCP
client is being made to act differently because of
IPv4ll. The correct fix
is to make sure that the DHCP client
does not in fact modify its behaviour to
make IPv4ll work, but rather to
modify IPv4ll so that it doesn't interfere
with the operation of the DHCP
client.
Lest you conclude that I am off my rocker, a way to check this
would be to
look for the place in RFC2131 where it says that the DHCP client
should wait
for five minutes after failing (that is, having retried and
timed out) to
contact a DHCP server, before reinitiating an attempt to
contact one. I
would direct your attention particularly to
section 4.1, which says nothing
like this.
Section 4.1 of RFC2131 is already pretty
explicit about what the DHCP
client is supposed to do - the problem is that
some popular DHCP clients
aren't doing this, because (I presume) their state
machines have been
tweaked to accomodate IPv4ll.
Actually, section 4.1 already says that the DHCP client shouldn't back off to
more than 64 seconds, so the DHCP client should be retrying roughly every 64
seconds if it's following RFC2131. Perhaps the IPv4ll spec needs
to make
clear that implementors of IPv4ll that also implement DHCP must
still follow
the recommendations put forth in RFC2131 section 4.1.
[Robert Elz]
| The correct fix is to make sure that the DHCP client does not
in
| fact modify its behaviour to make IPv4ll work, but rather to
modify
| IPv4ll so that it doesn't interfere with the operation of the
DHCP client.
I have no problem with that, that's what I'd do.
The problem that we have
is that everyone wants everything to fall into the
perfect state instantly.
Any time that we're in an unexpected state is
"broken", even if there's
nothing the implementation could really have done
about that.
That is, my approach to this, which I don't think conflicts
with the
drafts at all, would be to start the DHCP client (let it go do its
thing
just like it does now, ignoring LL addressing), wait a second and a
half
(puerly because of that 1 second boring meaningless non-answered ping
delay
verifying that the address is not assigned) and then see if I have an
address.
If not, configure an LL address as documented, and use that.
Then keep
monitoring the interface. If a routable address appears from
somewhere
(most likely from DHCP, but anywhere will do) mark the LL address
(if the
LL process has reached this stage yet) as deprecated - and yes, this
means
borrowing some (more) IPv6 innovation and terminology for v4 (which
is
really needed anyway to make dhcp work correctly - currently on the
stack
I use, if dhcp gives me a v4 address, then the lease expires, dhcp will
then
take away the address again - just as it should - but I can trivially
avoid
that just by killing my dhcp process, the IP stack has no concept at
all
of a lifetime for v4 addresses, if the dhcp process doesn't remove
the
address, it is permanent, it should have a valid time, just as v6
addresses do).
The issue I was detecting in the issue (LL34) though is
that once we're in
that state, we don't want to remain in it, if a routable
address should be
available - LL34 is trying to tell DHCP to keep trying hard
to get a
routable address.
| Lest you conclude that I am off my
rocker, a way to check this would be to
| look for the place in
RFC2131 where it says that the DHCP client should
| wait for five
minutes after failing (that is, having retried and timed out)
|
to contact a DHCP server, before reinitiating an attempt to contact
one.
No, I know that's not there - that's why I used the words
"operational
requirements" in the previous message - LL34 wants to force
implementations
to retry quickly. 2131 doesn't say "wait 5
minutes" but it also doesn't
say "don't wait 5 minutes", or "try again every
5 seconds" - something like
the latter is what LL34 seems to be asking of
DHCP (though it actually
says 1 minute, not 5 seconds, but hints that 30 secs
would be even better).
That's why I see this issue as an attempt to
change DHCP from the zeroconf WG.
The LL processing happens just the same,
other than wrt absolute times,
whatever the DHCP server does, but people want
it to happen quickly, not
slowly...
This is exacerbated with LL
addresses existing (the problem is made worse),
so now there's a greater
incentive to fix it.
Before LL, networking was simply broken, if no DHCP
address could be
obtained. That's a simple state - easy to
explain - easy for the user
to handle ("popop box says no dhcp server
responded, no address, no
networking - someone fix the dhcp server
please!"). With LL addresses
getting no routable address is
"expected", it isn't an error - the stack
just configures an LL address and
says "I'm ready, use me" - and the user
believes all is OK - except nothing
works. In this situation we really
want things to revert to
the "fixed" state as quickly as possible, lest
frustration result "where did
I get this stupid useless address instead
of the one I should have - the
network is broken".
[Ted Lemon]
Right, and if we just don't let the IPv4ll state machine reach out and touch
the DHCP state machine, this is precisely what will happen. That
is, the
DHCP client should never care about IPv4ll.
It is helpful,
however, for the IPv4ll agent to notice that the DHCP client
has timed out
in contacting the DHCP server. In this case, the DHCP client
will still configure its interface if it has a valid lease.
However, the
IPv4ll agent at this point should probably also configure an
IPv4ll address,
since the address the DHCP client is using is by no means
guaranteed to be
correct. So simply watching the interface isn't
going to get you the best
results for IPv4ll, although it's an improvement
over having the IPv4ll agent
reaching out and touching the DHCP client.
[Robert Elz]
| In this case, the DHCP client
| will still configure its
interface if it has a valid lease.
Yes, and in most circumstances where
that happens, that address will
work just as well as a LL address (the DHCP
client is supposed to
verify that the lease still makes some kind of sense -
it needs to do
that to choose between the several valid leases it might have
from
past assignments (I've had clients allocated multi-year leases from
some
weird servers, and sometimes had several of those simultaneously).
If
the DHCP client checks that the address seems functional before
assigning
it, then the LL address would only be useful in the rarest
cases.
| However, the IPv4ll agent at this point should probably
also configure
| an IPv4ll address, since the address the DHCP client
is using is by no
| means guaranteed to be correct.
That's true
- but no-one knows. The DHCP client doesn't (if it knew it
was
incorrect, it would not configure it, to know it is correct it needs
a DHCP
server response, which we are assuming does not happen), the LL
assignment
machinery has no idea, it just sees a non-LL address (and perhaps
the DHCP
timeout), but more than that, none of the applications that are
to use the
address know either. They're going to be faced with the
situation
of having a choice of 2 local addresses to use, and no idea which
one is
going to work better. In most cases, the (old) DHCP address
will
work fine, and probably reach more destinations than the LL address,
so
in most cases that is what the applications are going to want to use,
I
suspect. Given that, doing the extra work to assign an LL
address in this
scenario seems pointless.
| So simply watching
the interface isn't going to get you the best
| results for
IPv4ll,
If getting the best results for IPv4LL was an objective, I'd
probably
agree. But it isn't. Rather, IPv4LL is an
attempt to get the best
results for the system (or more likely, the system's
user). That is,
it doesn't matter in the slightest if IPv4LL
fails miserably, as long
as the end result is correct, and communications get
established,
at least in the vast majority of cases.
[Erik Guttman]
The text supplied by Bernard has the property that it does not
specify any
new behavior for DHCP. The new text makes it clear
that an
implementation of IPv4LL must attempt to obtain configuration
via DHCP
according to the DHCP specification, even if it has failed
to in the
past. I think this satisfies Ted's concern:
Ted Lemon
wrote:
> The correct fix is to make sure that the DHCP client does not in
fact
> modify its behaviour to make IPv4ll work, but rather to modify
IPv4ll
> so that it doesn't interfere with the operation of the DHCP
client.
[Bernard Aboba] The proposed resolution is to add the
following text to Section 2.3:
" Where a Link-Local IPv4 address is assigned, experience has shown
that
five minutes (see [IPv4LL] Appendix A.2) is too long an interval
to wait
until retrying to obtain a routable IPv4 address using DHCP.
According to
[RFC2131] Section 4.1:
The retransmission delay SHOULD be doubled
with
subsequent retransmissions up to a maximum of 64 seconds.
As a
result, a DHCP client compliant with [RFC2131] will continue to
retry every
64 seconds, even after allocating a Link-Local IPv4
address. Should the DHCP
client succeed in obtaining a routable
address, then as noted in [IPv4LL],
the Link-Local IPv4 address is
deprecated. In order to avoid inappropriate
assignment of an IPv4
Link-Local address, it is RECOMMENDED that such an
address not be
assigned until the DHCP client has retransmitted at least 3
times."
Proposed Resolution: Accept
Issue 6: SIRs Review
Submitter: Joel
Halpern
Submitter email address: joel@stevecrocker.com
Date first
submitted: September 15, 2003
Reference: http://www1.ietf.org/mail-archive/working-groups/dhcwg/current/msg02357.html
Document:
DNAv4-01
Comment
type: T
Priority: S
Section: Various
Rationale/Explanation of
issue:
Over all the draft is well written and clear. It is on the right track, but I
believe it could use some clarifications. In particular, two aspects seem to me
to be in need of assistance.
Firstly, the problem statement seems to be
missing a piece. While the concern being addressed is likely obvious to those
who work daily with DHCP and DHCP related issues, it is not obvious to a reader
from another community. In particular, I found myself asking why I would use the
reachability validation step rather than simply going directly to INIT-REBOOT
state and sending a DHCPREQUEST to the broadcast address. I suspect that the ARP
reachability verification mechanism is expected to be significantly faster and
to place less load on other parts of the system. But the document does not say
that.
Secondly, in the description of the reachability verification
mechanisms it would be helpful if there were a sentence indicating why the use
of the 0.0.0.0 source protocol address will be effective. (I checked the ARP
RFC< not having ARP code handy, and I understand that the ARP response
generation sends the response to the source hardware address. It would be
helpful to the reader if the document said this.) Related to this clarification,
it would probably be helpful to note (probably in an appendix) both whether this
behavior has been observed to cuase any strange ARP cache entries and whether
most observed implementations do indeed respond properly to the message proposed
here. (I know they should. However, the difference between theory and
practice...)
[Bernard Aboba] Proposed fixes are as follows:
Change the abstract to:
" The time required to detect movement (or lack of movement)
between
subnets, and to obtain (or continue to use) a valid IPv4 address
may
be significant as a fraction of the total delay in moving
between
points of attachment. This specification synthesizes
experience
garnered over the years in the deployment of hosts supporting
ARP,
DHCP and IPv4 Link-Local addresses, in order to optimize detection
of
network attachment by mobile hosts."
Add the following text to Section 1:
" The time required to detect movement (or lack of movement)
between
subnets, and to obtain (or continue to use) a valid IPv4 address
may
be significant as a fraction of the total delay in moving
between
points of attachment. As a result, optimizing detection of
network
attachment is important for mobile hosts."
Add the following text to Section 2.2:
" Since the ARP Response is sent to the sender hardware address,
the
contents of the sender protocol address field do not affect
delivery
of the ARP Response. Since existing implementations do not create
an
ARP cache entry for 0.0.0.0, using this as the sender protocol
address
is harmless."
Proposed Resolution: Accept
Issue 7: ARP contents
Submitter: Dieter
Siegmund
Submitter email address: dieter@apple.com
Date first submitted:
October 2, 2003
Reference:
Document: DNAv4-02
Comment
type: T
Priority: S
Section: 2.2
Rationale/Explanation of issue:
I have a comment regarding the
spec:
http://www.ietf.org/internet-drafts/draft-ietf-dhc-dna-ipv4-02.txt
In
section "2.2. Packet Format", it suggests sending an ARP probe
(sender IP
0.0.0.0) to check the router MAC address against a known value.
One
problem I've run into in the past (and still do today) is that some
routers
refuse to answer ARP probe's. In particular, the Cisco router here at
Apple,
and a FlowPoint DSL router I have at home only respond to an ARP Request
with
a "legitimate" sender IP address.
Have you also encountered
this?
Regards,
Dieter Siegmund
Core OS Networking
[BA] Here is the proposed fix:
In Section 2.2, change:
"Since the host has not yet confirmed the subnet on which
it is attached,
it MUST set the sender protocol address field
(ar$spa) to 0.0.0.0. This
prevents poisoning of the ARP cache with a
(potentially invalid) sender IPv4
address.
Since the ARP Response is sent to the sender hardware address,
the
contents of the sender protocol address field do not affect
delivery
of the ARP Response. Since existing implementations do not
create an
ARP cache entry for 0.0.0.0, using this as the sender
protocol
address is harmless."
To:
"If the host has a valid globally routable IP address on the most
likely point of attachment, then it SHOULD set the sender
protocol
address field (ar$spa) to that address. It is
assumed that the host had
previously done duplicate address
detection so that an address conflict is
unlikely.
However if the host has a private address as defined in
[RFC1918],
then it SHOULD set the protocol address field (ar$spa)
to
0.0.0.0. This is to avoid an address conflict in the case
where the
host has changed its point of attachment from one
private network to another.
Note: Some routers may refuse to answer an
ARP Request sent
with the protocol address field (ar$spa)
set to the unspecified address. In
this case the reachability
test will fail."
Proposed Resolution: Accept
Issue 8: DNA-02 Review
Submitter: Henrik
Levkowetz
Submitter email address: henrik@levkowetz.com
Date first
submitted: October 15, 2003
Reference: http://www.levkowetz.com/ietf/rfcmarkup.cgi?url=../ietf/reviews/review-ietf-dhc-dna-ipv4-03.txt&comments=HENRIK
Document:
DNAv4-02
Comment
type: E
Priority: S
Section: Various
Rationale/Explanation of
issue:
In Section 1.2. Terminology:
To ease the readibility for people not
familiar with the ARP rfc
(RFC 826) it might be good to mention that names of
the form
ar$xxx.. are names of fields in the Address Resolution ethernet
packet data, as described in the ARP RFC [RFC826]. Alternatively
give
definitions for ar$tpa, ar$sha, ar$spa, ar$tha, something
like
this:
"ar$sha ARP packet field: Source Hardware Address [RFC826]. The
hardware
(MAC) address of the originator of an ARP packet.
ar$spa ARP packet
field: Source Protocol Address [RFC826]. For IP
Address Resolution this is
the IP Address of the sender
of the ARP packet. If the sender address is
unknown,
this is set to 0.0.0.0.
ar$tha ARP packet field: Target
Hardware Address [RFC826]. The
hardware (MAC) address of the target of an ARP
packet,
or the broadcast address if the target hardware address
is
unknown.
ar$tpa ARP packet field: Target Protocol Address
[RFC826]. For IP
Address Resolution, the IP address for which one
desires
to know the hardware address."
In Section 2.1. Reachability
Test:
"[b] If the host does not have a valid routable IPv4 address
on
the network. Since Link-Local IPv4 addresses are a
last resort, these
addresses do not count as a valid
routable IPv4 address."
Link-Local
addresses are excluded from valid routable IPv4
addresses by the definition
in Section 1.2 "Terminology",
so I suggest rewriting as follows:
[b]
If the host does not have a valid routable IPv4 address on the
network. (A
Link-Local IPv4 address do not count as a valid
routable IPv4
address.)
In Section 2.2. Packet Format
"If the initial ARP Request
does not elicit a Response, the host waits
200ms and then sends another ARP
Request. If no ARP Response is
received in response to this second Request,
the host proceeds to the
IPv4 address acquisition phase. If a valid ARP
Response is received,
but cannot be matched against known networks, the host
assumes it has
moved subnets and moves on to the address acquisition
phase."
A motivation for the choice of 200ms would be good, both for
immediate understanding, and for later evaluation of possible
alternative
values.
In Section 2.3. IPv4 Address Acquisition:
"....the
DHCPREQUEST needs to be forwarded to and from the DHCP
server by a DHCP Relay
so that the response can be broadcast."
- I don't seem able to quite
understand what is meant by this.
(Anyway, RFC2131 indicates clearly in
4.3.6, with no exceptions
given elsewhere, that in INIT-REBOOT the client
sends messages
by broadcast.)
In Section 3. IANA
Considerations:
"Guidelines for IANA considerations are specified in
[RFC2434]. This
specification does not request the creation of any new
parameter
registries, nor does it require any other IANA
assignments."
Maybe skip the first sentence?
In Section 4.
Security Considerations:
Detection of Network Attachment (DNA) is
typically insecure, so that
it is inadvisable for a host to adjust its
security based on which
network it believes it is attached to. For example,
it would be
inappropriate for a host to disable its personal firewall based
on
the believe that it had connected to a home
network.
s/believe/belief/
In Section 5.1. Normative
References:
RFCs 792 and 2132 does not seem to be referenced in the
document text.
RFC 2434 is hardly normative as seen by the readers of the
document.
In Appendix A:
"On IEEE 802 [IEEE802] wired networks,
hints include link-layer
discovery traffic as well as information exchanged
as part of IEEE
802.1X authentication [IEEE8021X]. Link-layer discovery
traffic
includes Link Layer Discovery Protocol [IEEE8021AB] traffic as
well
as network identification information passed in the
EAP-
Request/Identity or within an EAP method exchange, as defined in
EAP
[RFC2284]."
I suggest adding the abbreviation LLDP:
"... Link Layer Discovery
Protocol (LLDP)"
so it's known when it's used in the next
paragraph.
In Appendix A:
"Thus, associating to the same SSID is a
necessary, but not
necessarily a sufficient condition, for remaining within
the same
subnet. While a Station associating to the same SSID may
not
necessarily remain within the same subnet; on the other hand,
a
Station associating to a different SSID is likely to have
changed
subnets."
Maybe rewrite for easier reading:
"Thus,
associating to the same SSID is a necessary, but not
necessarily a sufficient
condition, for remaining within the same
subnet: while a Station associating
to the same SSID may not
necessarily remain within the same subnet, a Station
associating
to a different SSID is likely to have changed subnets."
Proposed Resolution: Accept
Issue 9: Use of ARP in Reachability Test
Submitter name: Ralph Droms
Submitter email address: rdroms@cisco.com
Date first submitted: 10/16/2003
Reference:
Document: DNA-03
Comment type: T
Priority: S
Section: 2 Packet Format
Rationale/Explanation of issue:
In the fourth paragraph of section 2, the host performing the reachability
test is
instructed to look in the ARP response for the default gateway's MAC address
and IPv4 address in ar$tha and ar$tpa, respectively. However, according to
section
"Packet Reception" of RFC 826, the default gateway (the target of the ARP probe)
will return its MAC address and IPv4 address in ar$sha and ar$spa.
There is also a minor editorial nit - the text in the first three paragraphs
of section 2.2 doesn't explicitly describe what value should be used for
ar$tha (should be 0) in the ARP probe message.
Requested change: Change ar$tha and ar$tpa to ar$sha and ar$tha,
respectively, in the fourth paragraph of section 2.2
Add the following sentence to the end of the first paragraph in section 2.2:
"The host sets the target hardware address field (ar$tha) to 0."
Proposed Resolution: Accept
Issue 10: Strong vs. Weak hints
Submitter:
Bernard Aboba
Submitter email address: aboba@internaut.com
Date first
submitted: November 10, 2003
Reference:
Document: DNAv4-04
Comment type:
T
Priority: S
Section: Appendix A
Rationale/Explanation of issue:
The distinction between "strong" and "weak" hints is not entirely
clear to me. I think that the distinction does not affect protocol
operation -- it's just affects the likelihood of success.
For example, if there is any chance that a hint is not definitive, then
the host needs to do a check anyway (such as a reachability test or
a DHCPREQUEST). So behavior doesn't really change based on hint
strength.
The specification should say this. It's unclear now.
[BA] The proposed resolution is as follows:
Delete all mention of "strong" and "weak" hints from the draft.
Change Appendix A to the following:
"Appendix A - Hints
In order to assist in IPv4 network attachment detection,
information
associated with each network may be retained by the host.
Based on
IP and link-layer information, the host may be able to make an
educated guess as to whether it has moved between subnets, or
remained on the same subnet.
If the host is likely to have moved between subnets, it may be
possible to make an educated guess as to which subnet it has moved
to. Since an educated guess may be incorrect, prior to
concluding
that the host remains on the same subnet, further tests (such as a
reachability test or a DHCPREQUEST sent from the INIT-REBOOT state)
are REQUIRED.
IPv4 ICMP Router Discovery messages [RFC1256] provide information
relating to prefix(es) available on the link. A host may use
such a
message to conclude that an advertised prefix is available; however
it cannot conclude the converse -- that prefixes not advertised are
unavailable.
For networks running over PPP [RFC1661], IP parameters negotiated
in
IPCP provide direct information on whether a previously obtained
address remains valid on the link.
On IEEE 802 [IEEE802] wired networks, hints include link-layer
discovery traffic as well as information exchanged as part of IEEE
802.1X authentication [IEEE8021X].
Link-layer discovery traffic includes Link Layer Discovery Protocol
(LLDP) [IEEE8021AB] traffic as well as network identification
information passed in the EAP-Request/Identity or within an EAP
method exchange, as defined in EAP [RFC2284bis].
For example, LLDP advertisements can provide information on VLANs
supported by the device. When used with IEEE 802.1X
authentication
[IEEE8021X], the EAP-Request/Identity exchange may contain the name
of the authenticator, also providing information on the potential
network. Similarly, during the EAP method exchange the
authenticator
may supply information that may be helpful in identifying the
network
to which the device is attached. However, as noted in
[RFC3580], it
is possible for the VLANID defined in [IEEE8021Q] to be assigned
dynamically, so that static advertisements may not prove
definitive.
In IEEE 802.11 [IEEE80211] stations provide information in Beacon
and/or Probe Response messages, such as the SSID, BSSID, and
capabilities, as well as information on whether the station is
operating in Infrastructure or Ad hoc mode. As described in
[RFC3580], it is possible to assign a Station to a VLAN
dynamically,
based on the results of IEEE 802.1X [IEEE8021X] authentication.
This
implies that a single SSID may offer access to multiple VLANs, and
in
practice most large WLAN deployments offer access to multiple
subnets.
Thus, associating to the same SSID is a necessary, but not
necessarily a sufficient condition, for remaining within the same
subnet: while a Station associating to the same SSID may not
necessarily remain within the same subnet, a Station associating to
a
different SSID is likely to have changed subnets.
In IEEE 802.11, the SSID is a non-unique identifier, and SSIDs such
as "default", "linksys" and "tsunami" are often configured by
manufacturers by default. As a result, matching an
advertised SSID
against those of previously encountered networks may be misleading.
Where an SSID known to be configured by default is encountered, it
is
recommended that the BSSID be stored and subsequently compared
against the advertised BSSID to determine whether a match exists.
In order to provide additional guidance on the subnets to which a
given AP offers access, additional subnet-related Information
Elements (IEs) have been proposed for addition to the IEEE 802.11
Beacon and Probe Response messages. As noted earlier, VLANs
may be
determined dynamically so that these information elements may not
be
reliable."
Proposed Resolution: Accept
Issue 11: Reachability test
Submitter: Mark
Stapp
Submitter email address: mjs@cisco.com
Date first
submitted: November 11, 2003
Reference:
http://www1.ietf.org/mail-archive/working-groups/dhcwg/current/msg02702.html
Document: DNAv4-04
Comment type:
T
Priority: S
Section: 2.1
Rationale/Explanation of issue:
I have some comments on draft-ietf-dhc-dna-ipv4-04.txt - on section 2.1 in
particular.
[2.1] Reachability Test
Doesn't this sentence in 2.1 sort of turn DHCP on its head?
"The purpose of the reachability test is to determine whether
the host is connected to a network on which it had previously
obtained a still valid routable IPv4 address."
As I understand it, it's only the DHCP server who knows
authoritatively whether the address binding that the client
remembers is still valid. Working around that authority in
circumstances where the server has failed, if the client could
actually determine that, would be one thing. But working around
that without the client's even attempting to confirm its binding
with the server is problematic.
This section states that a host may skip confirmation of its DHCP
address when it reconnects under some circumstances. The DHCP
INIT-REBOOT state is actually pretty important, and skipping it
could have some undesireable consequences. As 2.1 is worded now, a
host could have a week-old memory of an address it got on network
A, and could re-use it upon reconnecting to network A without
attempting INIT-REBOOT. That's a pretty dramatic change, if I've
read the text accurately, and I'm not comfortable with it.
Is the goal of 2.1 to assist clients who have marginal connections
- wireless clients whose associations are flapping, for example?
Maybe a time-based, stateful heuristic would be appropriate
here. For example, if the host believes that it has reconnected to
network A, and that it last communicated with the DHCP server on
network A within the last - one minute? five minutes? - then it
could proceed without INIT-REBOOT. If the host had
a) been off of network A for more than five minutes, or
b) been attached to some other network since it last
attached to network A
then it would go through INIT-REBOOT normally.
Or are there folks who think that the client should always do
INIT-REBOOT if it can? In that case, if there's a latency issue
for some types of client or some types of link, maybe we should
try to make a low-latency answer available from the server without
changing the client behavior at all.
[Ted Lemon]
Some people have made a lot of what I would consider a misreading of RFC2131
- that INIT-REBOOT is optional. I believe it's optional because some hosts may
not have stable store, not because hosts that *do* have stable store should ever
skip INIT-REBOOT.
I think that in order to get good behavior in the case where we have flapping
going on on an 802.11 link, it's going to require a compromise on one of three
directions. The choices are (remember, this is just for 802.11):
- Try to do it right. This means that when we see a change, we look for a new
configuration but don't immediately throw out the old, in the sense that we keep
the old address configured alongside the new, and only kill it off after a
timeout has passed. I don't think that anybody is going to implement this, and
I'm not seriously proposing it - just wanted to mention it.
- Compromise in the direction of switching quickly. This means that when we
detect a possible change in attachment, we assume that the old connection is
gone and never coming back. So we throw it away immediately and switch. MacOS X
does this now. My wife Andrea was unable to get her email for quite a while this
afternoon as a result, because she has a Titanium, which has, shall we say,
antenna issues. She kept losing her access point in the middle of downloading
her email, so she got the same ten messages quite a few times before she gave
up.
- Compromise in the direction of switching slowly. AFAIK nobody does this now.
What this means is that when we notice a network transition, we keep it in mind,
but don't try to reconfigure immediately - we wait 90 seconds, long enough for
any active TCP sessions to time out. If, during that timeout period, the old
network comes back, we continue using it. After this period has passed, we give
up and move to the new network.
This is a point solution for 802.11. I think that aggressive switching probably
works fine for ethernet and similar media, because a change in media is usually
a physical process. The solutions proposed in DNAv4 having to do with not trying
to reconfigure until we actually detect a new link, as opposed to the loss of
the old link, make a lot of sense - this means that if the switch is power
cycled, we don't lose our address, but if we're plugged into a different switch,
we get a new address quickly.
[Mark Stapp] Couldn't quite tell from this whether you agreed with me that the
text in the draft was ... too general.
Like your wife, I've occasionally had 802.11 troubles, and I'd be interested in
providing some guidelines that would make it easier for an 802.11 client to deal
with those troubles better. I don't read INIT-REBOOT to mean 'throw out your
configuration.' I've read it as 'try to confirm that your configuration is still
valid'; there are lots of ways of optimizing the confirmation process. The dna
draft proposes optimizing it by avoiding it - skipping the confirmation message
based on some heuristic. The heuristic that's in the text isn't restricted to
802.11 clients, and isn't time-based or damped. The draft also doesn't discuss
interactions between L2 (which notices that the link has gone down and been
reconnected), the IP stack, and the DHCP client, and I agree with you that users
are most likely to notice a transient link problem if it takes down their TCP
connections.
I'd like to distinguish 'reconfiguration' from 'confirmation'. I agree that
helping 802.11 clients avoid unnecessary reconfiguration is desirable, and I'd
support text that made specific recommendations for those clients. But the -04
draft loses the benefits of confirmation in too many situations.
[BA] The proposed resolution is as follows:
Add the following definition to the terminology section (1.2):
"Valid address
In this specification, the term "valid address" refers
to either a
static IPv4 address, or an address assigned via DHCPv4
which has
not been relinquished, and whose lease has not yet
expired."
Change Section 2.2 to the following:
"2.2. Reachability Test
The purpose of the reachability test is to determine whether the
host
is connected to a network on which it has a valid routable IPv4
address.
The host skips the reachability test in the following
circumstances:
[a] If the host does not have a valid routable IPv4
address on the "most likely" point of
attachment.
[b] If reliable hints are unavailable. Since confirming
failure of the reachability test requires a
timeout,
mistakes are costly. In the absence
of reliable
hints, a host SHOULD instead send a
DHCPREQUEST from
the INIT-REBOOT state, as described in
[RFC2131],
Section 3.2 and 4.3.2.
[c] If the host does not have information on the default
gateway(s) for the "most likely" point of
attachment.
[d] If secure detection of network attachment is required.
See Section 5 for details.
The reachability test is performed by attempting to verify
reachability of default gateway(s) on the "most likely" point of
attachment. This reduces roaming latency by allowing the host
to
bypass DHCP as well as subsequent Duplicate Address Detection
(DAD).
In contrast to a DHCP exchange, which may be between a DHCP client
and an offlink DHCP server, the reachability test occurs between a
host and its next hop router.
The host may probe only the primary default gateway, or it may
probe
primary and secondary default gateways, in series or in parallel.
If
the reachability test is successful, the host may continue to use a
valid routable IPv4 address without having to re-acquire it.
However, in order to ensure configuration validity, the host
SHOULD
only configure default gateway(s) which pass the reachability
test."
Change Appendix A.1 to the following:
"A.1 Introduction
In order to assist in IPv4 network attachment detection,
information
associated with each network may be retained by the host.
Based on
IP and link-layer information, the host may be able to make an
educated guess as to whether it has moved between subnets, or has
remained on the same subnet, as well as whether it has connected to
an infrastructure or adhoc network.
If the host is likely to have moved between subnets, it may be
possible to make an educated guess as to which subnet it has moved
to. Since an educated guess may be incorrect, prior to
concluding
that the host remains on the same subnet, further tests (such as a
reachability test or a DHCPREQUEST sent from the INIT-REBOOT state)
are REQUIRED.
In practice, it is necessary for hints to be highly reliable before
they are worth considering, if the penalty paid for an incorrect
hint
is substantial.
As an example, assume that a DHCPREQUEST requires DHCPREQUEST_TIME
to
determine if a host has remained on the same subnet, while a
reachability test typically completes in REACH_TIME and times out
in
REACHABILITY_TIMEOUT, after which a DHCPREQUEST is sent.
If a hint that the host has remained on the same subnet is wrong x
fraction of the time, then it is only worth considering if:
DHCPREQUEST_TIME = (1 - x) * REACH_TIME +
x * (REACHABILITY_TIMEOUT + DHCPREQUEST_TIME)
x =
DHCPREQUEST_TIME - REACH_TIME
------------------------------------------------------------------------------
REACHABILITY_TIMEOUT +
DHCPREQUEST_TIME - REACH_TIME
If we assume that DHCPREQUEST_TIME = 100 ms, REACH_TIME = 10 ms,
and
REACHABILITY_TIMEOUT = 1000ms, then:
x = (100 - 10)/(1000 + 100 - 10) = 8.2 percent
Therefore the hint need only be wrong 8.2 percent of the time
before
it is not worth considering."
Proposed Resolution: Accept
Issue 12: Organizational Issues
Submitter:
Bernard Aboba
Submitter email address: aboba@internaut.com
Date first
submitted: January 25, 2004
Reference:
Document: DNAv4-04
Comment type:
T
Priority: S
Section: Various
Rationale/Explanation of issue:
Much of the material in Section 1 would do better if moved to Section 2,
Framework.
A separate section is needed for each of the three major stages of DNAv4:
Detection of network attachment, reachability test and IPv4 address assignment.
The section of packet format should be a sub-section of the reachability test
section 2.2.
Replace Section 1 with the following:
" The time required to detect movement (or lack of movement)
between
subnets, and to obtain (or continue to use) a valid IPv4 address
may
be significant as a fraction of the total delay in moving between
points of attachment. As a result, optimizing detection of
network
attachment is important for mobile hosts.
This document synthesizes experience in the deployment of hosts
supporting ARP [RFC826], DHCP [RFC2131], and Link-Local IPv4
addresses [IPv4LL], specifying a procedure to be performed for IPv4
detection of network attachment. The procedure consists
of three
phases: determination of the "most likely" point of attachment,
reachability testing, and IPv4 address acquisition."
Replace Section 2 with the following:
"2. Framework
For Detection of Network attachment, the following basic principles
are suggested:
[a] Utilization of hints. Link layers such as IEEE 802
[IEEE802] provide hints whether a host
remains
on the same subnet despite changing its
point of
attachment, or whether a host is connected
to an
ad hoc or infrastructure network.
Prior to connecting
to a new point of attachment, the host uses
available
hints to determine the "most likely"
configuration
associated with the new point of
attachment. Since
hints are not infallible, the host should
be capable of
making the correct determination even in
the presence of
misleading hints. For details see
Appendix A.
[b] Treatment of link-up indications. On connecting
to a new point of attachment, the host
attempts to
verify the "most likely" configuration
associated
with the new point of attachment.
[c] Treatment of link-down indications. On disconnection
from a network, there is no need to take
action until the
host is reconnected, since it is typically
not possible
for a host to communicate until it has
obtained connectivity.
Therefore, contrary to [RFC2131] Section
3.7, no action
need be taken on network disconnection.
[d] Handling of Link-Local IPv4 addresses. Experience has
shown that Link-Local IPv4 addresses are
often assigned
inappropriately. This document
suggests that hosts
behave conservatively with respect to
assignment of
Link-Local IPv4 addresses, configuring them
only in
situations in which they can do no harm.
2.1. Most likely point of attachment
In order to determine the "most likely" point of attachment it is
assumed that the host is capable of obtaining and writing to stable
storage parameters relating to networks that it connects to,
including:
[1] IP and link layer hints associated with each network.
For details, see Appendix A.
[2] The IPv4 and MAC address of the default gateway(s) on
each network.
[3] Whether a network is an infrastructure or adhoc network.
By matching the received hints against information previously
collected, the host may be able to make an educated guess of which
network it has attached to. In the absence of other
information, by
default the host assumes that the "most likely" point of attachment
is the network to which it was most recently attached.
If the host has a valid routable IPv4 address on the "most likely"
point of attachment, the host performs a reachability test as
described in Section 2.2. If the reachability test is not
successful, or if the host does not have a valid routable IPv4
address on the "most likely" point of attachment, the host proceeds
to the IPv4 address acquisition phase, described in Section 2.3.
2.2. Reachability Test
The purpose of the reachability test is to determine whether the
host
is connected to a network on which it has a valid routable IPv4
address.
The host skips the reachability test in the following
circumstances:
[a] If the host does not have a valid routable IPv4
address on the "most likely" point of
attachment.
[b] If reliable hints are unavailable. Since confirming
failure of the reachability test requires a
timeout,
mistakes are costly. In the absence
of reliable
hints, a host SHOULD instead send a
DHCPREQUEST from
the INIT-REBOOT state, as described in
[RFC2131],
Section 3.2 and 4.3.2.
[c] If the host does not have information on the default
gateway(s) for the "most likely" point of
attachment.
[d] If secure detection of network attachment is required.
See Section 5 for details.
The reachability test is performed by attempting to verify
reachability of default gateway(s) on the "most likely" point of
attachment. This reduces roaming latency by allowing the host
to
bypass DHCP as well as subsequent Duplicate Address Detection
(DAD).
In contrast to a DHCP exchange, which may be between a DHCP client
and an offlink DHCP server, the reachability test occurs between a
host and its next hop router.
The host may probe only the primary default gateway, or it may
probe
primary and secondary default gateways, in series or in parallel.
If
the reachability test is successful, the host may continue to use a
valid routable IPv4 address without having to re-acquire it.
However, in order to ensure configuration validity, the host
SHOULD
only configure default gateway(s) which pass the reachability test.
2.2.1. Packet Format
The reachability test is performed by sending an ARP Request.
The
ARP Request SHOULD use the host's MAC address as the source, and
the
broadcast MAC address as the destination. The host sets the
target
protocol address (ar$tpa) to the IPv4 address of the primary
default
gateway, and uses its own MAC address in the sender hardware
address
field (ar$sha). The host sets the target hardware address
field
(ar$tha) to 0.
If the host has a valid routable IPv4 address on the most likely
point of attachment, then it SHOULD set the sender protocol address
field (ar$spa) to that address. It is assumed that the host
had
previously done duplicate address detection so that an address
conflict is unlikely.
However if the host has a private address as defined in [RFC1918],
then it SHOULD set the sender protocol address field (ar$spa) to
the
unspecified address (0.0.0.0). This is to avoid an address
conflict
in the case where the host has changed its point of attachment from
one private network to another.
Note: Some routers may refuse to answer an ARP
Request sent with
the sender protocol address field (ar$spa) set to
the unspecified
address (0.0.0.0). In this case the reachability
test will fail.
If a valid ARP Response is received, the MAC address in the sender
hardware address field (ar$sha) and the IPv4 address in the sender
protocol address field (ar$spa) are matched against the list of
networks and associated default gateway parameters. If a
match is
found, then if the host has a valid routable IPv4 address on
the
matched network, the host continues to use that IPv4 address,
subject
to the lease re-acquisition and expiration behavior described in
[RFC2131], Section 4.4.5.
Checking for a match on both the IPv4 address and MAC address of
the
default gateway allows the host to confirm reachability even where
the host moves between two private networks. In this case the
IPv4
address of the default gateway could remain the same, while the MAC
address would change, so that both addresses need to be checked.
Sending an ICMP Echo Request [RFC792] to the default gateway IPv4
address does not provide the same level of assurance since this
requires an ARP Request/Response to be sent first, and typically
does
not allow the MAC address to be checked as well. It therefore
SHOULD
NOT be used as a substitute.
Where a host moves from one private network to another, an ICMP
Echo
Request can result in an ICMP Echo Response even when the default
gateway has changed, as long as the IPv4 address remains the same.
This can occur, for example, where a host moves from one home
network using prefix 192.168/16 to another one. In addition,
if the
ping is sent with TTL > 1, then an ICMP Echo Response can be
received
from an off-link gateway.
If the initial ARP Request does not elicit a Response, the host
waits
for REACHABILITY_TIMEOUT and proceeds to the IPv4 address
acquisition
phase. If a valid ARP Response is received, but cannot be
matched
against known networks, the host assumes it has moved subnets and
moves on to the address acquisition phase.
2.3. IPv4 Address Acquisition
If the host has a valid routable IPv4 address on the "most likely"
point of attachment, but the reachability test fails, then the host
SHOULD verify the configuration by entering the INIT-REBOOT state,
and sending a DHCPREQUEST to the broadcast address as specified in
[RFC2131] Section 4.4.2.
If the host does not have a valid routable IPv4 address on the
"most
likely" point of attachment, the host enters the INIT state and
sends
a DHCPDISCOVER packet to the broadcast address, as described in
[RFC2131] Section 4.4.1.
If the host does not receive a response to a DHCPREQUEST or
DHCPDISCOVER, then it retransmits as specified in [RFC2131] Section
4.1.
As discussed in [RFC2131], Section 4.4.4, a host in INIT or
REBOOTING
state that knows the address of a DHCP server may use that address
in
the DHCPDISCOVER or DHCPREQUEST rather than the IPv4 broadcast
address. In the INIT-REBOOT state a DHCPREQUEST is sent to
the
broadcast address so that the host will receive a response
regardless
of whether the previously configured IPv4 address is correct for
the
network to which it has connected.
Sending a DHCPREQUEST to the unicast address in INIT-REBOOT state
is
not appropriate, since if the DHCP client has moved to another
subnet, a DHCP server response cannot be routed back to the
client
since the DHCPREQUEST will bypass the DHCP relay and will contain
an
invalid source address.
2.4. IPv4 Link-Local Addresses
Link-Local IPv4 addresses are frequently assigned inappropriately.
For example, an IPv4 host assigning a Link-Local IPv4 address may
not
be connected to a network, in which case assignment of a Link-Local
IPv4 address does no good; or the host may be attached to a network
with a DHCPv4 server but may not receive a response to a
DHCPREQUEST
or DHCPDISCOVER.
To avoid inappropriate assignment of Link-Local IPv4 addresses, it
is
recommended that hosts behave conservatively with respect to
assignment of Link-Local IPv4 addresses.
As described in [IPv4LL] Section 1.7, use of a routable address is
preferred to a Link-Local IPv4 address whenever it is available.
For
example, where the host does not have a valid routable IPv4 address
on the "most likely" point of attachment, the host MAY configure an
IPv4 Link-Local address prior to entering the INIT state and
sending
a DHCPDISCOVER packet, as described in Section 2.3. Should a
routable IPv4 address be obtained, then as noted in [IPv4LL], the
Link-Local IPv4 address is deprecated.
Where the DHCP client does not receive a response after employing
the
retransmission algorithm a minimum of three times, the host MAY
configure a Link-Local IPv4 address.
Where a host has a valid routable IPv4 address on the "most likely"
point of attachment, but the DHCP client does not receive a
response
after employing the retransmission algorithm, [RFC2131] Section 3.2
states that the client MAY choose to use the previously allocated
network address and configuration parameters for the remainder of
the
unexpired lease. This is preferable to assigning a Link-Local
IPv4
address if hints lead the host to believe that it remains connected
to a point of attachment on which it possesses a valid routable
IPv4
address.
Since a Link-Local IPv4 address is often configured because a DHCP
server failed to respond to an initial query or is inoperative for
some time, it is desirable to abandon the Link-Local IPv4 address
assignment as soon as a valid IPv4 address lease can be obtained.
As described in [IPv4LL] Appendix A, once a Link-Local IPv4 address
is assigned, existing implementations do not query the DHCPv4
server
again for 5 minutes. This behavior is in violation of
[RFC2131]
Section 4.1.
Where a Link-Local IPv4 address is assigned, experience has shown
that five minutes (see [IPv4LL] Appendix A.2) is too long an
interval
to wait until retrying to obtain a routable IPv4 address using DHCP.
According to [RFC2131] Section 4.1:
The retransmission delay
SHOULD be doubled with
subsequent
retransmissions up to a maximum of 64 seconds.
As a result, a DHCP client compliant with [RFC2131] will continue
to
retry every 64 seconds, even after allocating a Link-Local IPv4
address. Should the DHCP client succeed in obtaining a
routable
address, then as noted in [IPv4LL], the Link-Local IPv4 address is
deprecated."
Proposed Resolution: Accept
Issue 13: Introduction Should State Goal of
Document
Submitter: Erik Guttman
Submitter email address:
erik.guttman@sun.com
Date first
submitted: April 14, 2004
Reference:
Document: DNAv4-06
Comment type:
E
Priority: 2
Section: Abstract
Rationale/Explanation of issue:
Please change
This specification synthesizes experience
garnered over the years in the deployment of hosts supporting ARP,
DHCP and IPv4 Link-Local addresses, in order to optimize detection of
network attachment by mobile hosts.
To
This document synthesizes experience
garnered over the years in the deployment of hosts supporting ARP,
DHCP and IPv4 Link-Local addresses. A procedure is specified for
detection of network attachment in order to best accomodate mobile
hosts.
[Bernard Aboba] The proposed resolution is as follows.
Change the abstract to:
" The time required to detect movement (or lack of movement) between
subnets, and to obtain (or continue to use) a valid IPv4 address may
be significant as a fraction of the total delay in moving between
points of attachment. This document synthesizes experience garnered
over the years in the deployment of hosts supporting ARP, DHCP and
Link-Local IPv4 addresses. A procedure is specified for detection of
network attachment in order to better accommodate mobile hosts."
Proposed Resolution: Accept
Issue 14: Applicability of Document
Submitter: Erik Guttman
Submitter email address:
erik.guttman@sun.com
Date first
submitted: April 14, 2004
Reference:
Document: DNAv4-06
Comment type:
T
Priority: 1
Section: All
Rationale/Explanation of issue:
This document applies to IPv4. I believe IPv6 ND and RAs specifically
greatly simplify the task of detecting network attachment. Since all
the algorithms and protocols discussed in this document are IPv4
specific, I believe an applicability statement should be added either to
the introduction or as a new section. Here is some suggested text to
start the discussion:
Add to the end of the Introduction:
This document concerns the interaction of mechanisms used by IPv4
protocol stacks. Network attachment detection and its interaction
with interface configuration is considered elsewhere, for example
in Neighbor Discovery for IPv6 [RFC2461], IPv6 Stateless
Address Autoconfiguration [RFC2462] and Mobility Support in IPv6
[MIPv6].
For the informative references section:
[RFC2460]
[RFC2461]
[MIPv6] draft-ietf-mobileip-ipv6-24.txt
[Bernard Aboba] The proposed resolution is as follows:
Change the Introduction to:
" The time required to detect movement (or lack of movement) between
subnets, and to obtain (or continue to use) a valid IPv4 address may
be significant as a fraction of the total delay in moving between
points of attachment. As a result, optimizing detection of network
attachment is important for mobile hosts.
This document synthesizes experience in the deployment of hosts
supporting ARP [RFC826], DHCP [RFC2131], and Link-Local IPv4
addresses [IPv4LL], specifying a procedure to be performed for IPv4
detection of network attachment. The procedure consists of three
phases: determination of the "most likely" point of attachment,
reachability testing, and IPv4 address acquisition.
This document concerns the interaction of mechanisms used by IPv4
protocol stacks. Network attachment detection and its interaction
with interface configuration is considered elsewhere, for example in
Neighbor Discovery for IPv6 [RFC2461], IPv6 Stateless Address
Autoconfiguration [RFC2462] and Mobility Support in IPv6 [MIPv6]."
Add the following non-normative references:
[RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998.
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[MIPv6] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in
IPv6", draft-ietf-mobileip-ipv6-24.txt, June 2003.
Proposed Resolution: Accept
Issue 15: Eavesdropping Routing Protocols
Submitter: Erik Guttman
Submitter email address:
erik.guttman@sun.com
Date first
submitted: April 14, 2004
Reference:
Document: DNAv4-06
Comment type:
T
Priority: 2
Section: 2.1
Rationale/Explanation of issue:
I believe several IP stacks have the ability to eavesdrop OSPF and
RIP and deduce which router(s) to forward to. This is not a bad
practice. If done well, the host can process periodic announcements
and determine the best egress router. Even if the routing protocol
"best next hop" calculation is not performed, routers will redirect
traffic. That is, even a naive inference of router location by
those routers which emit LSAs, etc. is better than nothing, right?
[Bernard Aboba] See the proposed resolution of Issue 16.
Proposed Resolution: Accept
Issue 16: Say Something About RFC 1256
Submitter: Erik Guttman
Submitter email address:
erik.guttman@sun.com
Date first
submitted: April 14, 2004
Reference:
Document: DNAv4-06
Comment type:
T
Priority: 1
Section: 2.1, 2.2
Rationale/Explanation of issue:
ICMP router discovery could be used actively and passively to
determine the existence of a router, to verify their "most likely"
point of attachment. I have heard that in practice very few deployed
routers enable this protocol and few IPv4 protocol stacks use it. I
believe for completeness, this approach should be discussed, although
only to discourage it. I do not recall hearing what the problem with
this approach was, apart from the fact that it is poorly supported.
It is unfortunate that this approach is not available. Router discover
would improve the 'reachability test' in section 2.2 to make it robust in cases
where a known router is not available while another router is available
but not known.
[Bernard Aboba] Add Section 1.1.1:
"Aside from utilizing link layer hints, a host may also be able to
utilize Internet layer information in order to determine the
"most likely" point of attachment.
IPv4 ICMP Router Discovery messages [RFC1256] provide
information relating to prefix(es) available on the link, as well
as the routers that serve those prefix(es). A host may
use ICMP Router Discovery to conclude that an advertised prefix is available;
however it cannot conclude the converse -- that prefixes not
advertised are unavailable.
However, since [RFC1256] is not widely implemented,
in general, it is NOT RECOMMENDED that hosts utilize
ICMP Router Discovery messages as an alternative to the reachability
test outlined in Section 2.2. Instead, ICMP Router Advertisements can
be used to obtain information on available prefixes and default
gateway(s). This can provide additional resilience in
the case where default gateway(s) become unavailable.
Similarly, hosts that support routing protocols such as RIP
and OSPF can use these protocols to determine the prefix(es)
available on a link and the default gateway(s) that serve those
prefixes."
Proposed Resolution: Accept
Issue 17: Use Link Sense if Possible
Submitter: Erik Guttman
Submitter email address:
erik.guttman@sun.com
Date first
submitted: April 14, 2004
Reference:
Document: DNAv4-06
Comment type:
T
Priority: S
Section: 2.4
Rationale/Explanation of issue:
" For example, an IPv4 host assigning a Link-Local IPv4 address may not
be connected to a network, in which case assignment of a Link-Local
IPv4 address does no good"
If a system can sense active links, this should be encouraged, right?
Why not reword this to say:
In the case where an IPv4 host assigning a Link-Local IPv4 address
is not connected to a network, assignment of a Link-Local IPv4
address does no good.
[Bernard Aboba] The proposed resolution is as follows:
Change Section 2.4 to the following:
"2.4. Link-Local IPv4 Addresses
To avoid inappropriate assignment of Link-Local IPv4 addresses, it is
recommended that hosts behave conservatively with respect to
assignment of Link-Local IPv4 addresses. As described in [IPv4LL]
Section 1.7, use of a routable address is preferred to a Link-Local
IPv4 address whenever it is available.
Where the host does not have a valid routable IPv4 address on the
"most likely" point of attachment, the host MAY configure an Link-
Local IPv4 address prior to entering the INIT state and sending a
DHCPDISCOVER packet, as described in Section 2.3. However, should a
routable IPv4 address be obtained, the Link-Local IPv4 address is
deprecated, as noted in [IPv4LL].
Where a host has a valid routable IPv4 address on the "most likely"
point of attachment, but the DHCP client does not receive a response
after employing the retransmission algorithm, [RFC2131] Section 3.2
states that the client MAY choose to use the previously allocated
network address and configuration parameters for the remainder of the
unexpired lease. Where a host can confirm that it remains connected
to a point of attachment on which it possesses a valid routable IPv4
address, that address SHOULD be used, rather than assigning a Link-
Local IPv4 address.
Since a Link-Local IPv4 address is often configured because a DHCP
server failed to respond to an initial query or is inoperative for
some time, it is desirable to abandon the Link-Local IPv4 address
assignment as soon as a valid IPv4 address lease can be obtained.
As described in [IPv4LL] Appendix A, once a Link-Local IPv4 address
is assigned, existing implementations do not query the DHCPv4 server
again for 5 minutes. This behavior is in violation of [RFC2131]
Section 4.1.
Where a Link-Local IPv4 address is assigned, experience has shown
that five minutes (see [IPv4LL] Appendix A.2) is too long an interval
to wait until retrying to obtain a routable IPv4 address using DHCP.
According to [RFC2131] Section 4.1:
The retransmission delay SHOULD be doubled with
subsequent retransmissions up to a maximum of 64 seconds.
As a result, a DHCP client compliant with [RFC2131] will continue to
retry every 64 seconds, even after allocating a Link-Local IPv4
address. Should the DHCP client succeed in obtaining a routable
address, then as noted in [IPv4LL], the Link-Local IPv4 address is
deprecated."
Proposed Resolution: Accept
Issue 18: Further Examples of Problematic IPv4LL
Use
Submitter: Erik Guttman
Submitter email address:
erik.guttman@sun.com
Date first
submitted: April 14, 2004
Reference:
Document: DNAv4-06
Comment type:
T
Priority: S
Section: 2.4
Rationale/Explanation of issue:
Even if a host avoids problematic IPv4 LL configuration, there are other
hosts which will not. In order to mitigate this, hosts should be
prepared to interact with link-local hosts.
Add:
Some hosts, in some circumstances, will inevitably inappropriately
configure IPv4 LL addresses. In order to effectively communicate
with these hosts, all hosts SHOULD be able to respond to such peers
which are in this state, as per [IPv4LL] For example, a host
configured with a routable address receives a datagram from a
link-local source address. In order to respond to an address in
the link-local address prefix, the host will respond to the same
link. Further, the host will use ARP to resolve the target
hardware address and send the datagram directly, not to a router
for forwarding.
[Bernard Aboba] The proposed resolution is as follows:
Add the following paragraph to the end of Section 2.4:
"Since it is inevitable that hosts will inappropriately configure
Link-Local IPv4 addresses at some point, hosts with routable IPv4
addresses SHOULD be able to respond to peers with Link-Local IPv4
addresses, as per [IPv4LL]. For example, a host configured with a
routable address may receive a datagram from a link-local source
address. In order to respond, the host will use ARP to resolve the
target hardware address and send the datagram directly, not to a
router for forwarding."
Proposed Resolution: Accept
Issue 19: Review of DNA-07
Submitter: Jim
Busse
Submitter email address:
jimbusse@pacbell.net
Date first
submitted: June 5, 2004
Reference:
Document: DNAv4-07
Comment type:
T
Priority: S
Section: Various
Rationale/Explanation of issue:
The DNA sentence "On disconnection from a network, there is no
need to take action until the host is reconnected" does not reflect the
state of Windows communications stacks in numerous products. In fact,
action is required so applications' various function calls don't hang and
sometimes blue screen the client. As a test, take a win98 SE client, open IE
and go to a page that takes a long time to load. During the load,
disconnect the Ethernet cable, and hit the refresh button 8-10 times.
You'll BSOD.
Regarding the reachability section 2.2, it's unclear whether the items
a,b,c,d are "and'ed" or "or'ed" for truth. Or, it may take a and c for
truth, or b for truth, for example--it's just not clear. I did a truth
table based on the standard, and one of my engineers did a truth table after
reading the document, and both were different.
The other item regarding reachability: you of course have much more
experience than I, but we have found the case where gateways are unreachable
for one reason or another (sometimes for lengthy periods of time), but the
proxy server is reachable, and it looks to the user like a gateway is
there--who knows the difference? So for a client with fixed IP
configuration, when the gateway goes down, the reachability test will fail,
a link-local address will be assigned, and the next instance of the browser
won't be able to reach the proxy server. The gateway will come back up, but
a DHCP address won't be assigned because the client started with a fixed IP
configuration but now has a link-local address assigned. The link-local
address isn't DHCP assigned, and Windows won't release it.or renew it. The
only way we found to get Windows to dump the LL address was to stop and
restart the interface with the registry set to the correct values for the
restart. This of course trashes all pending transactions and can be harmful
to some applications. Like IE--you need to close it and re-open it.
That was the purpose of my original question, and your response was
correct--just the fact that you can't reach it now doesn't mean you should
assign and use a new address. So the implementers of the standard will be
confused: just when *should* you assign and use a new address? (rhetorical
question).
[Bernard Aboba] Here is the proposed resolution:
In Section 2, delete:
"[c] Treatment of link-down indications. On disconnection
from a network, there is no need to take action until the
host is reconnected, since it is typically not possible
for a host to communicate until it has obtained connectivity.
Therefore, contrary to [RFC2131] Section 3.7, no action
need be taken on network disconnection."
In Section 2.2, change [a]-[d] to the following:
[a] The host does not have a valid routable IPv4
address on the "most likely" point of attachment.
In this case, it is not possible to confirm that
the host has a valid routable IPv4 address, so
that the reachability test is unnecessary.
[b] The host does not have information on the default
gateway(s) for the "most likely" point of attachment.
In this case, it is not possible to carry out the
reachability test.
[c] Reliable hints are unavailable. Since confirming
failure of the reachability test requires a timeout,
mistakes are costly. In the absence of reliable
hints, a host SHOULD instead send a DHCPREQUEST from
the INIT-REBOOT state, as described in [RFC2131],
Section 3.2 and 4.3.2. Where reliable hints are
unavailable, this will on average complete more
quickly than the reachability test.
[d] If secure detection of network attachment is required.
The reachability test utilizes ARP which is insecure,
whereas DHCP can be secured via DHCP authentication,
described in [RFC3118]. See Section 5 for details.
Proposed Resolution: Discuss
Issue 20: Most Likely Point of Attachment
Submitter name: Ralph Droms
Submitter email address: rdroms@cisco.com
Date first submitted: 10/16/2003
Reference:
http://www1.ietf.org/mail-archive/web/dhcwg/current/msg02473.html
Document: DNA-03
Comment type: E
Priority: 1
Section: 1.2
Rationale/Explanation of issue:
The phrase '"most likely" point of attachment' is used throughout the
document but
is never defined. Other, similar phrases are occasionally used, such as
'"most likely"
network' in the fourth paragraph of section 2.3.
Requested change: Add a definition for '"most likely" point of
attachment' to the terminology section. Define an acronym
MLPA for the phrase. Use the acronym throughout the document.
Note that, as much as I dislike the proliferation of acronyms
in IETF documents, in this case I think an acronym, suitably
defined in the Terminology section, would add clarity.
[Greg Daley]
In DNA BoF, we're obviously interested in having
common terminology across the set of techniques
(v4/v6) to detect network attachment.
There's currently some work in the BoF on
getting terminology worked out.
So that we don't slow anything down in DHC-WG,
maybe we can help contribute to the terms here, and
clone them into DNA. Does that sound reasonable?
In this case, is it sufficient to define
the most likely point of attachment, or
do we also need to define "point of attachment"?
I myself am clear what a point of attachment is.
Is the meaning unambiguous to others, or
would it simplify the definition of the
MLPA to have a definition of the point of
attachment?
Here are some initial attempts at
both options:
--
Most Likely Point of Attachment (MLPA):
The IP subnet and router combination
the host is most likely to be connected
to the network through. This is heuristically
determined by the host itself by hints
from the network.
--
Alternatively:
--
Point of Attachment:
A location within the network, where a host
may be connected. This attachment point
can be characterized by its address prefix
and next hop routing information.
Most Likely Point of Attachment (MLPA):
The point of attachment heuristically
determined by the host to be most likely,
based on hints from the network.
[Bernard Aboba] Here is the proposed resolution:
Add the following definitions to the terminology
section:
Point of Attachment:
A location within the network, where a host
may be connected. This attachment point
can be characterized by its address prefix
and next hop routing information.
Most Likely Point of Attachment (MLPA):
The point of attachment heuristically
determined by the host to be most likely,
based on hints from the network.
Use the abbreviation "MLPA" throughout the document.
Proposed Resolution: Discuss
Issue 21: Review of DNA-07
Submitter name: Soohong Daniel Park
Submitter email address: soohong.park@samsung.com
Date first submitted: 6/23/2004
Reference:
http://www1.ietf.org/mail-archive/web/dhcwg/current/msg03663.html
Document: DNA-07
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:
My comments are as below;
[1] Category is correct as PS ? I think BCP would be better.
[2] 1. Introduction,
>This document concerns the interaction of mechanisms used by IPv4
>protocol stacks. Network attachment detection and its interaction
>with interface configuration is considered elsewhere, for example in
>Neighbor Discovery for IPv6 [RFC2461], IPv6 Stateless Address
>Autoconfiguration [RFC2462] and Mobility Support in IPv6 [MIPv6].
I am not sure why this draft refers rfc2461,2462 and even MIPv6.
This draft is strictly bound to IPv4 especially DHCPv4 and IPv4LL
and something like that, so I think we don't need to refer IPv6 protocol.
[3] 2.3 IPv4 Address Acquisition
To obtain its IPv4 address quickly, Rapid Commit option of DHCPv4
can be used for optimizing detection of network attachment on mobile
hosts. With my experience, it's stable and fast than current
mechanism, thus if feasible, you can indicate this utility at this section.
http://www.ietf.org/internet-drafts/draft-ietf-dhc-rapid-commit-opt-03.txt
(I updated and published it as 04 version yesterday)
For reference, I cite a result of comparison between them.
(It was tested on both wired and wireless though testbed was so simple)
===========================================
Item Mean value Standard deviation
===========================================
Time delay
(sec.) Existing 0.051269 0.002349
New 0.001541 0.001213
===========================================
Packet loss
(packet) Existing 417.04 53.10322
New 366.02 32.55092
===========================================
[Bernard Aboba] Here is the proposed resolution:
Change Section 1 to the following:
"The time required to detect movement
(or lack of movement) between subnets, and to obtain (or continue to use) a
valid IPv4 address may be significant as a fraction of the total delay
in moving between points of attachment. As a
result, optimizing detection of network attachment is important for
mobile hosts.
This document synthesizes experience in the deployment of hosts supporting
ARP [RFC826], DHCP [RFC2131], and Link-Local IPv4 addresses [IPv4LL],
specifying a procedure to be performed for IPv4 detection of network
attachment. The procedure consists of three phases:
determination of the Most Likely Point of Attachment (MLPA), reachability
testing,
and IPv4 address acquisition."
Add the following sentence to Section 2.3:
"If the host supports the Rapid Commit Option [RAPID], it is
possible that the exchange can be shortened from a 4-message
exchange to a 2-message exchange."
Add the following Informative reference:
[RAPID] Park, S., Kim, P., and B. Volz, "Rapid Commit Option for DHCPv4",
Internet draft (work in progress), draft-ietf-dhc-rapid-commit-opt-05.txt, June
2004.
Proposed Resolution: Discuss
Issue 22: IP/Link Layer Interactions
Submitter name: Erik Nordmark
Submitter email address: erik.nordmark@sun.com
Date first submitted: 7/1/2004
Reference:
Document: DNA-07
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:
> The host may take into consideration both 1) router IP address & 2) router
MAC address.
I think looking at the source MAC address in the L2 header
also has some unfortunate architectural implications since it would make
it harder for IP to run over arbitrary link layers.
Today IP only assumes that the sender must be able to map the next-hop
IP address to something needed to send packets (be it an L2 address or
some local virtual-curcuit ID), but there is no requirement that
layer 2 present the senders L2 address for received packets.
If it did it is unclear to me what this would be for things like frame relay
which use VCIs.
Even if we constrain ourselves to IEEE 802 media, the fact that
Ethernet and FDDI uses different *bit* order for the IEEE addresses
would be a source of concerns.
So it's served IP well to never look at the addresses in the L2 headers
on reception.
> Also I recently heard a horror story that there are certain machines whose
> interfaces have not only the same link-local address but also the same
> link-layer address.
The original Ethernet specification said that the Ethernet address was
allocated to a "station" and not to a network interface card. Way back there
was even some protocol that required that a node with multiple NICs had the
same Ethernet address on all its NICs (could have been IPX or decnet).
Thus it is perfectly ok, albeit a bit uncommon today, to find
boxes with the same Ethernet address on all their NICs.
And if the MAC address is the same as a result the link-local address
will be the same.
> I think that where it makes sense to ensure that the MAC address
> matches (for example, where it was available in previous messages,
> in the SLLAO of an advertisement), then that's OK.
Using the SLLAO content doesn't have the issues relating to looking into
the L2 header for an L2 address, but I still don't see how using the SLLAO
would help in detecting whether the link is the same or different.
This is because the content of the SLLAO is not required to be globally unique:
for some link layers the addresses might be local, and for other link layers
it might be the case that a single router is allowed to use the same SLLAO on
different interfaces.
Thus receiving a RA with the same SLLAO as earlier is not indicating that
the host is on the same link as earlier.
Furthermore, since routers can come and go as well as change their
link-layer address (or have multiple interfaces with different link-layer
addresses for some load distribution across interfaces [latter is mentioned
in RFC 2461]) the reception of a RA with a SLLAO content which has never
been received before, is not an indication that the host is attached to a new
link either.
Since the SLLAO content can err in either direction (same when on different
link, and different when on same link) it doesn't even seem useful
as a hint pointing in any particular direction.
The global prefixes assigned to a link is what is needed (until routers
start advertising some form of link-id in the RAs) to make the determination.
Once you do that I don't see how adding SLLAO into the mix would improve
anything.
[Bernard Aboba] Given that the reachability test is dependent on ARP
and not
the IP layer, I believe that these considerations do not
apply.
Proposed Resolution: Reject
Issue 23: AD Review
Submitter name: Margaret Wasserman
Submitter email address: margaret@thingmagic.com
Date first submitted: March 21, 2005
Reference:
http://www1.ietf.org/mail-archive/web/dhcwg/current/msg04751.html
Document: DNA-09
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:
The only text in the document that might explain this seems to be:
In contrast to a DHCP exchange, which may be between a DHCP client and an off-link DHCP server, the reachability test is designed to verify bi-directional connectivity to the default gateway(s) on the MLPA.
[Bernard Aboba]
(1) Could you explain why sending an ARP request to the default gateway(s) of the MLPA (as described in section 2.2) is a better mechanism to confirm what IPv4 configuration parameters should be used than re-initiating DHCPv4 and/or attempting to renew the DHCPv4 lease (as described in section 2.3)?
Has there been some analysis and/or empirical testing that shows that this mechanism produces superior results?
(2) Is it assumed that the host would not send any non-DNA-related IPv4 traffic using its presumed address on the MPLA during the reachability test and address acquisition phases? If so, would it make sense to state that restriction here?
Do you expect that packets would be queued until the address status is resolved? Or that upper layers would receive errors consistent with an interface that has not addresses configured?
> I don't think this assumption is required. If the lease is still valid,
> sending packets prior to completion of DNA cannot result in an address
> conflict, and MAC learning needs to occur anyway.
I think it can result in an address conflict, in the case where a client
moves between two networks who both use the same ipv4 default router
(example: RFC1918 space), and for some reason have the same MAC address
(example: RFC2338 VRRP using the same VRID).
DNA would be fooled into using its previously bound ipv4 address, which
may not in fact belong to it. Damage which may be considered more
substantial than the benefits of avoiding a ~100ms delay.
But that combination of examples is not a very common configuration in
practice.
What you meant to say was that DNA does not cause any new forms of
address conflict which are not done already by hosts not implementing
DNA or similar.
The fact that the DNA client does something, anything, to verify its
address, should be considered a substantial improvement.
> I don't believe it is necessary to queue packets pending completion of DNA,
> only pending receipt of an L2 "link up" event. From the point of view of
> the host, if DNA is successful and the host confirms its existing IP
> configuration, there was no point during which the IP configuration became
> invalid; the host was attached to the same network all along. An error
> message is only required if the configuration changes.
If I had been paying attention when this WG item was discussed, I think
I would have suggested language to at least suggest the client should
not respond to ARP for its address, along with the already present "SHOULD
NOT send ICMP echo requests", until DNA completes is a reasonable
attempt to mitigate all forms of address conflict damage.
In the case where a client has not moved networks, it probably also has
a fresh ARP cache entry on its router and peers it has spoken to recently,
and is unlikely to start a new conversation within ~100ms anyway...so this
is probably reasonable, and still gives DNA a benefit where it is most
desired?
It may also be that a client implementing DNA could compare the source
ethernet mac address against the contents of arp$spa to detect RFC2338
and similar conditions without the need for manual configuration, but
I'm not sure on that point.
[Bernard Aboba]
>I think it can result in an address conflict, in the case where a client
>moves between two networks who both use the same ipv4 default router
>(example: RFC1918 space), and for some reason have the same MAC address
>(example: RFC2338 VRRP using the same VRID).
Use of VRRP/HSRP to protect against failure of the default gateway does not
cause a problem. The bi-direction reachability test requires that both the
IP Address and MAC address match, and so the DNA client will think it is on
the same network (which it is). The only situation which would cause a
problem is if routers with RFC 1918 addresses had duplicate MAC addresses.
This is very uncommon.
>DNA would be fooled into using its previously bound ipv4 address, which
>may not in fact belong to it. Damage which may be considered more
>substantial than the benefits of avoiding a ~100ms delay.
DNA checks both the IP address and the MAC address of the default gateway.
So reuse of an RFC 1918 address is not a problem unless the MAC address is
also reused.
>What you meant to say was that DNA does not cause any new forms of
>address conflict which are not done already by hosts not implementing
>DNA or similar.
Correct.
>The fact that the DNA client does something, anything, to verify its
>address, should be considered a substantial improvement.
DNA clients don't verify their addresses; they verify that they remain on a
network in which they already have a valid address. That is, DNA is only
carried out on an address which has a valid lease and which has completed
duplicate address detection.
>If I had been paying attention when this WG item was discussed, I think
>I would have suggested language to at least suggest the client should
>not respond to ARP for its address, along with the already present "SHOULD
>NOT send ICMP echo requests", until DNA completes is a reasonable
>attempt to mitigate all forms of address conflict damage.
The case to worry about is movement between RFC 1918 networks. Until the
client gets a reply from the default router, it does not know if it is on
the same network or not. But in the case where the client has an RFC 1918
address, it also doesn't know whether its address is valid or not. I agree
that where the host has an RFC 1918 address, it should probably not answer
an ARP request until it has completed DNA. However, where the host has a
valid routable address, I don't think that the host needs to wait, because
duplicate address detection has previously been completed.
>In the case where a client has not moved networks, it probably also has
>a fresh ARP cache entry on its router and peers it has spoken to recently,
>and is unlikely to start a new conversation within ~100ms anyway...so this
>is probably reasonable, and still gives DNA a benefit where it is most
>desired?
I think it is reasonable for the RFC 1918 case. I am not clear that it is
needed where the client already has a valid routable address.
[Bernard Aboba] Here is the proposed resolution:
Change the Abstract to the following:
Abstract The time required to detect movement (or lack of movement) between subnets, and to obtain (or continue to use) a valid IPv4 configuration may be significant as a fraction of the total delay in moving between points of attachment. This document specifies a procedure for optimizing the detection of network attachment and IP configuration in order to decrease the delay in moving between points of attachment.
Change the Section 1 to the following:
"1. Introduction The time required to detect movement (or lack of movement) between subnets, and to obtain (or continue to use) a valid IPv4 address may be significant as a fraction of the total delay in moving between points of attachment. As a result, optimizing detection of network attachment is important for mobile hosts. This document synthesizes experience in the deployment of hosts supporting ARP [RFC826], DHCP [RFC2131], and IPv4 Link-Local addresses [IPv4LL], specifying a procedure for optimizing detection of network attachment and IPv4 configuration. Since this procedure is dependent on the ARP protocol, it is not suitable for use on media that do not support ARP [RFC826]."
Change Section 2 to the following:
"2. Overview
DNAv4 consists of three phases: determination of the Most Likely
Point of Attachment (MLPA), reachability testing, and IPv4 address
acquisition.
On connecting to a new point of attachment, the host responds to
"Link Up" indications from the link layer by carrying out the DNAv4
procedure. As noted in Appendix A, hints about the point of
attachment may be available from the link and Internet layers.
Based
on these hints, the host determines the "Most Likely Point of
Attachment" (MLPA) and determines whether it has a valid
configuration associated with it.
If the host believes that it has attached to a network on which it
has a valid configuration, then it performs a reachability test in
order to confirm that configuration. In contrast to a DHCP
exchange,
which may be between a DHCP client and an off-link DHCP server, the
reachability test is designed to verify bi-directional connectivity
to the default gateway(s) on the MLPA.
If the reachability test is successful, the host MAY continue to
use
a valid routable IPv4 address without having to re-acquire it.
This
reduces roaming latency by allowing the host to bypass DHCP as well
as subsequent Duplicate Address Detection (DAD). If the host
believes that it has attached to a network on which it has no valid
configuration, or if the reachability test fails, then the host
attempts to obtain an IPv4 configuration using DHCP.
Since DNAv4 represents a performance optimization, it is important
to
avoid compromising robustness. In some circumstances, DNAv4
may
result in a host successfully verifying an existing IP
configuration
where attempting to obtain configuration via DHCP would fail (such
as
when the DHCP server is down).
While the performance of DNAv4 is dependent on the reliability of
the
hints provided to the client, the host will ultimately determine
the
correct IPv4 configuration even in the presence of misleading
hints.
Where the host mistakenly concludes that it has attached to a
network
on which it has a valid configuration a timeout will occur,
providing
poorer performance than would be experienced by initially
attempting
to obtain IP configuration using DHCPv4. However, after
timing out,
the host will obtain its configuration using DHCPv4, so that the
correct configuration will eventually be obtained.
To improve robustness, this document suggests that hosts behave
conservatively with respect to assignment of IPv4 Link-Local
address,
configuring them only in situations in which they can do no harm.
Experience has shown that IPv4 Link-Local addresses are often
assigned inappropriately, and that inappropriate assignment can
compromise both performance and connectivity.
DNAv4 does not increase the likelihood of an address conflict.
The
DNAv4 procedure is only carried out when the host has a valid
address
on the MLPA, implying that duplicate address detection has
previously
been completed.
The risk of an address conflict is greatest when the host moves
between private networks, since in this case the completion of
Duplicate Address Detection on the former network does not provide
assurance against an address conflict on the new network. As
a
result, until a host has verified the validity of its IPv4
configuration, it SHOULD NOT respond to ARP requests. In
addition,
prior to confirming its IP configuration, a host with a private
address SHOULD NOT send ARP requests containing its address within
the sender protocol address field (ar$spa); instead it SHOULD
use
the unspecified address, as described in Section 2.2.1.
However,
where the host has a valid routable non-private address on the MLPA,
it MAY send ARP requests using its address within the sender
protocol
address field (ar$spa) prior to validating its IPv4 configuration."
Change Section 2.2 to the following:
"2.2. Reachability Test
If the host has a valid routable IPv4 address on the MLPA, a host
conforming to this specification SHOULD perform a reachability
test,
in order to to confirm that it is connected to network on which it
has a valid routable IPv4 address. If the reachability test
is not
successful, the host proceeds to the IPv4 address acquisition
phase,
described in Section 2.3.
The host skips the reachability test and proceeds to the IPv4
address
acquisition phase if any of the following conditions are true:
[a] The host does not have a valid routable IPv4
address on the MLPA. In this case,
the reachability
test cannot confirm that the host has a
valid
routable IPv4 address, so that completing
the
reachability test would serve no purpose.
[b] The host does not have information on the default
gateway(s) on the MLPA. In this case,
insufficient
information is available to carry out the
reachability
test.
[c] Reliable hints are unavailable. Since confirming
failure of the reachability test requires a
timeout,
mistakes are costly. In the absence
of reliable
hints, a host SHOULD instead send a
DHCPREQUEST from
the INIT-REBOOT state, as described in
[RFC2131],
Section 3.2 and 4.3.2. Where reliable
hints are
unavailable, this will typically complete
more
quickly than the reachability test.
[d] If secure detection of network attachment is required.
The reachability test utilizes ARP which is
insecure,
whereas DHCP can be secured via DHCP
authentication,
described in [RFC3118]. See Section 5
for details.
The host MAY probe only the primary default gateway, or it MAY
probe
primary and secondary default gateways, in series or in parallel.
In
order to ensure configuration validity, the host SHOULD only
configure default gateway(s) which pass the reachability test.
2.2.1. Packet Format
The reachability test is performed by sending an ARP Request.
The
ARP Request SHOULD use the host's MAC address as the source, and
the
broadcast MAC address as the destination. The host sets the
target
protocol address (ar$tpa) to the IPv4 address of the primary
default
gateway, and uses its own MAC address in the sender hardware
address
field (ar$sha). The host sets the target hardware address
field
(ar$tha) to 0.
If the host has a valid routable IPv4 address other than a private
address [RFC1918] on the most likely point of attachment, then it
SHOULD set the sender protocol address field (ar$spa) to that
address. It is assumed that the host had previously done
duplicate
address detection so that an address conflict is unlikely.
However if the host has a private address as defined in [RFC1918],
then it SHOULD set the sender protocol address field (ar$spa) to
the
unspecified address (0.0.0.0). This is to avoid an address
conflict
in the case where the host has changed its point of attachment from
one private network to another.
Note: Some routers may refuse to answer an ARP
Request sent with
the sender protocol address field (ar$spa) set to
the unspecified
address (0.0.0.0). In this case the reachability
test will fail.
If a valid ARP Response is received, the MAC address in the sender
hardware address field (ar$sha) and the IPv4 address in the sender
protocol address field (ar$spa) are matched against the list of
networks and associated default gateway parameters. If a
match is
found, then if the host has a valid routable IPv4 address on
the
matched network, the host continues to use that IPv4 address,
subject
to the lease re-acquisition and expiration behavior described in
[RFC2131], Section 4.4.5.
Checking for a match on both the IPv4 address and MAC address of
the
default gateway enables the host to confirm reachability even where
it has moved between two private networks. In this case the
IPv4
address of the default gateway could remain the same, while the MAC
address would change, so that both addresses need to be checked.
Sending an ICMP Echo Request [RFC792] to the default gateway IPv4
address does not provide the same level of assurance since this
requires an ARP Request/Response to be sent first. Where the
host
has moved between two private networks, this could result in ARP
cache pollution.
Where a host moves from one private network to another, an ICMP
Echo
Request can result in an ICMP Echo Response even when the default
gateway has changed, as long as the IPv4 address remains the same.
This can occur, for example, where a host moves from one home
network using prefix 192.168/16 to another one. In addition,
if the
ping is sent with TTL > 1, then an ICMP Echo Response can be
received
from an off-link gateway. As a result, if the MAC address of
the
default gateway is not checked, then the host could mistakenly
conclude that it remained on the same network, when in fact it had
moved, potentially resulting in an address conflict. As a
result,
sending of an ICMP Echo Request SHOULD NOT be used as a substitute
for the DNAv4 procedure.
If the initial ARP Request does not elicit a Response, the host
waits
for REACHABILITY_TIMEOUT and proceeds to the IPv4 address
acquisition
phase. If a valid ARP Response is received, but cannot be
matched
against known networks, the host assumes it has moved subnets and
moves on to the IPv4 address acquisition phase."
Proposed Resolution: Accept
Issue 24: Conflict with ACD Draft
Submitter name: James Carlson
Submitter email address: james.d.carlson@sun.com
Date first submitted: April 28, 2005
Reference:
Document: DNA-11
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:
While trying to implement these mechanisms, I think I've found a
conflict between these two documents. I realize that it's pretty late
(you're already in AD review), but could you please look into this?
In the linklocal draft, section 2.2.1 says:
new pseudo-random address and repeat the process. In addition, if
during this period the host receives any ARP probe where the packet's
'target IP address' is the address being probed for, and the packet's
'sender hardware address' is not the hardware address of the
interfaces the host is attempting to configure, then the host MUST
similarly treat this as an address collision and select a new address
as above. This can occur if two (or more) hosts attempt to configure
the same IPv4 Link-Local address at the same time.
This means that if a request (ares_op$REQUEST) packet with ar$spa set
to zero and ar$tpa set to the local address is received (a "probe"),
then we should treat it as a collision and not assign the address.
Unfortunately, the dna draft uses *exactly* these probe packets in its
section 2.2.1 to detect whether the "primary default gateway" is
reachable:
The reachability test is performed by sending an ARP Request. The
ARP Request SHOULD use the host's MAC address as the source, and the
broadcast MAC address as the destination. The host sets the target
protocol address (ar$tpa) to the IPv4 address of the primary default
gateway, and uses its own MAC address in the sender hardware address
field (ar$sha). The host sets the target hardware address field
(ar$tha) to 0.
If the host has a private address as defined in [RFC1918], then it
SHOULD set the sender protocol address field (ar$spa) to the
unspecified address (0.0.0.0). This is to avoid a potential address
conflict when the host changes its point of attachment from one
private network to another.
The end result of this is that if the router and some arbitrary end
node connect at the same time, the router will see the "reachability
probes" from the end node and *incorrectly* assume that someone else
is claiming his address -- and thus fail to assign the address
properly.
The three possible resolutions I can see are:
- Change the dna draft so that it requires a *regular* ARP
Request message (ar$spa set to the local address), and
requires that the system does any linklayer-draft related
probing before attempting to do reachability.
- Change the linklayer draft to remove that second clause --
so that probes are not seen as conflicts.
- Just live with it, because if routers fail to operate in
practice, that's fine. (Or because I've missed something
really important that prevents the problem, though I don't
see what.)
For what it's worth, I see the first of those three as the most
reasonable. Probing someone else's address with an ar$spa set to zero
doesn't make a lot of sense to me.
--
James Carlson, KISS Network <james.d.carlson@sun.com>
Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677
[Bernard Aboba]
Thanks very much for these comments. In DNAv4 the probe is used to
confirm reachability of the default router on the MLPA. The default
router address may be a private address, or it may be a globally routable
address, but it should never be a linklocal address in 169.254/16.
Therefore it should not cause a conflict with IPv4 Link Local
address assignment. If it would help, we could explicitly state that a
probe MUST NOT be sent to a default router with an IPv4 Link Local
address.
[James Carlson]
I think that would likely help a bit, but I'm still concerned that,
due to the expired Cheshire duplicate address detection draft that
eerily mirrors the linklocal draft, there are likely to be
implementations that use the probing procedure for _all_ addresses,
not just those described in linklocal.
In other words, if folks are detecting duplicate addresses using
probes (as I strongly suspect they are), then the dna probe will still
cause problems, even if it's never probing a link-local address.
[Bernard Aboba]
The reason why arp$spa is set to zero when the default gateway has a
private address is that it is possible for a host to have changed networks
without changing prefixes. For example, the host could move from one home
network to another home network, both of which have a gateway address of
192.168.1.1. If arp$spa contained the actual address of the host then
this could pollute the ARP table.
[James Carlson] Yes, I realize that.
I think it's reasonable to observe, though, that just a few cases
exist and none of them lead to needing to set ar$spa to zero:
Private address happens to be in the range of the local
network (i.e., risk of pollution):
Address node has isn't currently in use, and thus use
of the address in ar$spa is harmless, even if the
address is 'from' another network and even if it might
"pollute" the local ARP caches. This can be checked
by doing DAD (probe own address) first.
Address node has is in use by another node on the new
network, in which case the node is on a new network or
just has to start over. Can terminate effort (without
probing default gateway) immediately. This can be
checked by doing DAD first.
Private address is not in the range of the local network
(i.e., no risk of pollution because no valid node is using
that address):
DAD will tell node that address is "ok" to use, as
it's not currently in use, but subsequent real
resolution (nonzero ar$spa) of the default router will
show that either it's at a different hardware address
or just doesn't respond.
In other words, I don't see a case in which a probe as defined in
linklocal needs to be used, provided that duplicate address detection
is available. There's nobody to poison.
[Bernard Aboba]
> In other words, if folks are detecting duplicate addresses using
> probes (as I strongly suspect they are), then the dna probe will still
> cause problems, even if it's never probing a link-local address.
Do you know of an example of this? I wouldn't be surprised if hosts send
probes with ar$spa set to zero to detect duplicates (since this
avoids polluting the ARP cache if there is a duplicate out there).
It's assuming that these probes imply a duplicate that seems a bit
unusual.
> In other words, I don't see a case in which a probe as defined in
> linklocal needs to be used, provided that duplicate address detection
> is available. There's nobody to poison.
Unfortunately, the point of using DNAv4 is to avoid DAD. If DAD were
required it would be faster to just send a DHCPREQUEST to verify the
address and forget DNAv4 altogether. We could specify that behavior when
the host has a private address, if it were necessary to avoid setting
ar$spa to zero.
[James Carlson]
> Do you know of an example of this? I wouldn't be surprised if hosts send
> probes with ar$spa set to zero to detect duplicates (since this
> avoids polluting the ARP cache if there is a duplicate out there).
I'll bet that Stuart Cheshire does; that's why I copied him. The
behavior described above is from Apple.
> It's assuming that these probes imply a duplicate that seems a bit
> unusual.
Except that's exactly what the current zeroconf linklocal draft says.
See section 2.2.1 of that draft, where it says this:
new pseudo-random address and repeat the process. In addition, if
during this period the host receives any ARP probe where the packet's
'target IP address' is the address being probed for, and the packet's
'sender hardware address' is not the hardware address of the
interfaces the host is attempting to configure, then the host MUST
similarly treat this as an address collision and select a new address
as above. This can occur if two (or more) hosts attempt to configure
the same IPv4 Link-Local address at the same time.
This is exactly the probe we're talking about.
[Bernard Aboba]
I just reread the following document:
http://www.watersprings.org/pub/id/draft-cheshire-ipv4-acd-03.txt
It includes the following statement:
This document standardizes the widely-used natural interpretation of
an ARP Request where the Target Protocol Address is non-zero but the
Sender Protocol Address is zero, namely that it is a question without
an associated assertion (an "ARP Probe").
The idea that the probe is a statement without an assertion is backed up
by the text in Section 2.4:
Address conflict detection should not be limited to only the time of
initial interface configuration, when a host is sending ARP probes.
Address conflict detection is an ongoing process that is in effect
for as long as a host is using an address. At any time, if a host
receives an ARP packet (request *or* reply) where the 'sender IP
address' is (one of) the host's own IP address(es), but the 'sender
hardware address' does not match any of the host's own interface
addresses, then this is a conflicting ARP packet, indicating some
other host also thinks it is validly using this address. To resolve
the address conflict, a host must respond to a conflicting ARP packet
as described in either (a), (b) or (c) below:
I read this as implying that a probe with ar$spa set to zero is not
interpreted as a conflict.
[Stuart Cheshire]
>I think that would likely help a bit, but I'm still concerned that,
>due to the expired Cheshire duplicate address detection draft that
>eerily mirrors the linklocal draft, there are likely to be
>implementations that use the probing procedure for _all_ addresses,
>not just those described in linklocal.
James is right. This behavior is common today -- my draft just documents
it.
>I read this as implying that a probe with ar$spa set to zero is not
>interpreted as a conflict.
Except when two hosts are probing simultaneously. Then each treats the
other's probe as a conflict. This is necessary to avoid the simultaneous
probing race condition.
[James Carlson]
> Unfortunately, the point of using DNAv4 is to avoid DAD. If DAD were
> required it would be faster to just send a DHCPREQUEST to verify the
> address and forget DNAv4 altogether. We could specify that behavior when
> the host has a private address, if it were necessary to avoid setting
> ar$spa to zero.
That'd solve the problem completely.
(I think it'd also be conceptually cleaner, as basing the detailed
behavior of ARP on address ranges seems a bit suspect to me.)
Bernard Aboba writes:
> The idea that the probe is a statement without an assertion is backed up
> by the text in Section 2.4:
Yep.
> I read this as implying that a probe with ar$spa set to zero is not
> interpreted as a conflict.
Read on -- that draft and the zeroconf draft both say that when you
get a probe where the target is the address you're trying to verify,
you assume there's a conflict. They allow for two cases: the usual
ar$spa update that causes DAD failure *and* a probe of ar$tpa that
causes failure.
[BA] I think the discussion has narrowed the scenarios in which a
problem could occur:
1) When the default gateway has a linklocal address.
Since DNA wasn't meant to be used in this case, it can be
explicitly prohibited by adding condition e) to Section 2.2:
"e) If the default gateway address is an IPv4 Link-Local address."
2) When the host and gateway are sending ARP probes simultaneously.
The specific text in ACD-03 is as follows:
"In addition, if during this period the host receives any ARP probe where
the packet's 'target IP address' is the address being probed for, and
the packet's 'sender hardware address' is not the hardware address of
any of the host's interfaces, then the host MUST similarly treat this
as an address conflict and signal an error to the configuring agent
as above. This can occur if two (or more) hosts have, for whatever
reason, been inadvertently configured with the same address, and both
are simultaneously in the process of probing that address to see if
it can safely be used."
However, a router would be unwise to behave this way, because:
a. A router typically has no "configuring agent" (human operator,
DHCP server, etc.), and would become unreachable if it were to
abandon its address, taking network connectivity down with it.
b. A router with a statically configured IP address would be unwise
to stop usage of its address based on receipt of an ARP probe, since that
would make it vulnerable to a denial of service attack. Instead, the router
should only interpret an ARP reply as a true conflict, and should respond
to an ARP probe if it has verified its own address. This would ensure that
a router would win an address conflict battle, imposing the least cost on
the network as a whole.
Note that for a problem to occur, a default gateway would need
to use ARP probes to verify its address, would need to interpret
receipt of a probe while probing as an actual (not potential) address
conflict, and would need to stop use of its address as a result
of a conflict detected via receipt of a probe.
I will do some tests on common routers (Cisco, Linksys, Apple Airport, etc.) to
see how they behave
and will also send out an implementation survey.
NB: I would also argue that any host with a static address would be unwise
to behave as advocated in ACD-03, since such a host could not easily obtain
another address to use instead and would therefore become disabled.
[Bernard Aboba] Here's what the initial tests seem to show:
Proteon and related code bases: ARP announcement
Cisco IOS: Broadcast ARP Reply
Linksys: No DAD prior to use of an address (no ARP announcement or Probe)
[Bernard Aboba]
The crux of this issue concerns whether routers have implemented:
http://www.watersprings.org/pub/id/draft-cheshire-ipv4-acd-03.txt
The jury is still out on this (I've sent out an implementation survey and
am doing some testing of existing routers). However, from what I've found
so far, this doesn't appear to be common.
Here is the proposed resolution:
Add condition [e] in Section 2.2:
" The host skips the reachability test and proceeds to the IPv4 address
acquisition phase if any of the following conditions are true:
...
[e] If the default gateway address is an IPv4 Link-Local
address. In this case, it is possible that the
reachability test could be misinterpreted as
indication of an address conflict. See [RFC3927]
Section 2.2.1 for details."
Also, change: " Note: Some routers may refuse to answer an ARP Probe, in which case the reachability test will fail." To: " Note: Some routers may refuse to answer an ARP Probe, in which case the reachability test will fail. A host also may encounter a router that utilizes ARP Probes for DAD, as described in [ACD]. Such routers will not interpret ARP Probes as an indication of an address conflict, except where they are themselves doing Duplicate Address Detection (DAD). To avoid triggering conflict detection on these routers, a host implementing DNAv4 that receives ARP Probe from a router SHOULD NOT send ARP Probes to that router as part of the DNAv4 reachability test." [James Carlson] I don't think that note actually fixes anything, because the probe this local node is sending occurs so soon after attachment that there's no way for the local node to know whether that router being probed does duplicate address detection or not. It can't just guess. Fundamentally, I'm unconvinced that using ARP probe messages for two different purposes in the network is actually sound. The hole we're carving here is that routers using private addresses must avoid DAD because they'll very likely face a storm of DAD-looking packets on start-up (e.g., switch powered back on). But since (a) any system may become a router by configuration and (b) routers are explicitly encouraged to use static assignment of addresses (see, for example, the in my opinion flawed advice in RFC 2131 section 1.3), we're just setting operators (and implementors -- like me) up for failure. Instead of sending a probe of some other node's address as though we were preparing to *use* that address as our own (the operation that I believe to be flawed), it makes sense to me that the node should first validate that its own address is not a duplicate on the "new" network by probing its own address (using DAD), and *then* sending out a regular ARP request (not a probe) for the router's IP address to verify that the local network is the same as before. I realize that waiting for the local address to pass DAD potentially makes the procedure slower than desired (perhaps as long as a second, if shortened timers are used), but leaving DAD in this completely ambiguous state (is it an actual conflict, or is it just an innocuous probe? -- no way to tell) is a far worse outcome. Alternatively, the following text needs to be struck from the DAD documents (and implementations): [...] In addition, if during this period the host receives any ARP Probe where the packet's 'target IP address' is the address being probed for, and the packet's 'sender hardware address' is not the hardware address of the interface the host is attempting to configure, then the host MUST similarly treat this as an address conflict and select a new address as above. [Bernard Aboba] To be clear, I'm not saying that routers shouldn't implement DAD. I think the issue is whether a router should give up its address on receiving an ARP Probe (e.g. sender address unspecified). I've sent out an implementation survey and tested a number of routers. None of them send out ARP Probes, and neither do they give up their address on receiving an ARP Probe. For example, the Cisco router I tested broadcasted an ARP Reply; Proteon and related code bases broadcast an ARP announcement; the LINKSYS router I looked at does not do DAD prior to using an address at all. So in practice, routers don't seem to treat ARP Probes as evidence of a conflict. The question is whether they should. In thinking this over, I believe that the existing behavior is in fact correct. A router should not give up a configured address easily -- since this would result in a service outage for hosts. Giving up an address in response to a question (ARP Probe) would make routers more fragile. > Instead of sending a probe of some other node's address as though we > were preparing to *use* that address as our own (the operation that I > believe to be flawed) The ACD document indicates that it is the "ARP Announcement" (send address = target address) that is an assertion, not the ARP Probe. The ARP Probe is described as a "question without an assertion". So I don't believe an ARP Probe can be interpreted as an indication that a host is intending to use an address. > Alternatively, the following text needs to be struck from the DAD > documents (and implementations): > > [...] In addition, if > during this period the host receives any ARP Probe where the packet's > 'target IP address' is the address being probed for, and the packet's > 'sender hardware address' is not the hardware address of the > interface the host is attempting to configure, then the host MUST > similarly treat this as an address conflict and select a new address > as above. At a minimum, I'd advocate that this text be restricted to hosts. Since no routers appear to implement it, this wouldn't require an implementation change. [Stuart Cheshire] 3. Probe packets The document struggles with its incompatibility with the existing widespread use of a zero-sender ARP as an ARP Probe, which means, "I want to know if this address is in use, AND IF NOT I INTEND TO USE IT MYSELF." This is the issue James Carlson pointed out. This document needs an ARP Request with these semantics: "I just want to know if this address is in use, and I have no intention of claiming it as my own address; I may believe I already have an address of my own, but I'm not yet willing to reveal what that is." What could that packet be? Given that the host does not want to announce its address until it is certain of it, it can't put that address in ar$spa. The host can't put zero in ar$spa, because that implies, "I intend to use ar$tpa as my own." Therefore, it has to put something else. It just has to be a non-zero value that can't be an actual IP address already in use by a host on that link. There are many possibilities: 0.0.0.1 127.0.0.1 255.255.255.255 Any of those values would work. They are not zero, so the packet doesn't look like a probe, and they're not any IP address that could be in use by any other host on that link, so they can't inadvertently stomp over someone else's ARP cache entry. Fixing this would eliminate much of the specification that's currently awkward, clumsy, self-contradictory and unimplementable. For example: Note: Some routers may refuse to answer an ARP Probe, in which case the reachability test will fail. A host also may encounter a router that utilizes ARP Probes for DAD, as described in [ACD]. Such routers will not interpret ARP Probes as an indication of an address conflict, except where they are themselves doing Duplicate Address Detection (DAD). To avoid triggering conflict detection on these routers, a host implementing DNAv4 that receives ARP Probe from a router SHOULD NOT send ARP Probes to that router as part of the DNAv4 reachability test. A host "that receives ARP Probe from a router SHOULD NOT..." How does a host KNOW it will receive ARP Probes from a router? How long should it wait to see? DNA is supposed to be fast, right, so how long do we want it to wait? Even after it's waited, how does it know the router is not booting up and, at that very instant, is about to send its own ARP Probes? How does a host know it's a router sending ARP Probes, and not some other host on the network performing DNA? What does it mean by, "SHOULD NOT send ARP Probes to that router as part of the DNAv4 reachability test"? I thought that sending ARPs was ALL of the DNAv4 reachability test. What other parts are there? Using ARP Requests with a 0.0.0.1 source address would eliminate all of these self-contradictions and awkward special cases. [John Schnizlein] I don't see any struggle between the probe definition here and what is in RFC 2131: "The client SHOULD perform a check on the suggested address to ensure that the address is not already in use. For example, if the client is on a network that supports ARP, the client may issue an ARP request for the suggested request. When broadcasting an ARP request for the suggested address, the client must fill in its own hardware address as the sender's hardware address, and 0 as the sender's IP address, to avoid confusing ARP caches in other hosts on the same subnet." I see no need to invent other source-IP addresses, which could only confuse things. The extra semantics of signaling intentions which might or might not be acted upon are superfluous. What document specifies that use of zero as the source IP address implies that the host intends to use the target IP address? I cannot see how using any value other than source-IP-address = zero could possibly solve the case where a router refuses to answer an ARP probe. Is it that a router that refuses to answer an ARP probe with zero as its source IP address might answer a probe with a different source IP address? Because there is no single universal solution for an IPv4 host to determine if/to-what network it is attached, the comprehensive identification of valuable hints seems appropriate. [Bernard Aboba] This problem originates because when the host is testing reachability on a private network, it is possible that it has connected to a MLN, but not the instance that it had anticipated. By sending a broadcast ARP Request with its own IPv4 address in arp$spa, the host pollutes the ARP cache. To avoid this, one possible solution is to avoid putting its own address in arp$spa. However, another possible solution is to unicast the ARP Request with its own IPv4 address in arp$spa. This addresses the concern about ARP cache pollution, since only the destination gateway will receive the request. If the gateway is not present, then the reachability test will timeout. [James Carlson] Ah, and since we have a cached copy of the gateway's MAC address, and it must be unique, we also avoid polluting the gateway's cache even if both ar$spa and ar$tpa are present on the 'new' network. I like it! > If the host has a private address as defined in [RFC1918], then > it SHOULD set the sender protocol address field (ar$spa) to that > address. To avoid potential ARP cache pollution, the ARP Request > SHOULD use the host's MAC address as the source, and the default > gateway MAC address as the destination. The host sets the target Why not simplify and just _always_ do it this way, regardless of address "type?" Doing so would detangle the draft from RFC 1918 and (as a side benefit) provide some help to those poor fools who still run private networks not enshrined in RFC 1918. > Sending an ICMP Echo Request [RFC792] to the default gateway IPv4 > address does not provide the same level of assurance since this may > require an ARP Request/Reply exchange. Where the host has moved > between two private networks, this could result in ARP cache > pollution. Not that it matters now, but you know your presumed local IP address, your local MAC address, the presumed gateway IP address, and the presumed gateway MAC address, so no ARP Request/Reply exchange would be needed and the above would be perfectly safe. However, it's not at all safe from violence due to VRRP. When you've failed over to a backup router, VRRP dictates that the router MUST NOT respond to traffic addressed to the router itself -- including ICMP. This means that ping fails when VRRP fail-over is in effect. Plus, there are more than a few routers that just don't respond to ping at all due to strange ideas some administrators have about configuration. Thus, I wouldn't use ping at all. [Bernard Aboba] In case of failover, is it not possible for a router with another MAC address to take over the original gateway address? Otherwise, I think that a unicast ARP Request works just as well. [James Carlson] "Take over" in what way? If you're talking about VRRP, then, no. Both the primary and the backup are required to use a "virtual" MAC address to avoid having to update everyone's ARP cache entries. See RFC 3768 section 8.2. If you're talking about HSRP, the same is true. See RFC 2281 section 6.1. If you're just talking about the general case with multiple independent egress routers on a single network, then, yes, it's certainly possible for one to fail while the node is incommunicado, and another to be 'the primary' one when the node returns. However, I'd argue that such a case is really just another instance of a network reconfiguration where the returning node is going to have to take the slow path to figure out its surroundings. > The issue with ping doesn't apply to ARP, right? Correct. ARP is an exception, because it's not IP. VRRP prohibits responses from the backup using the IP address that is "owned" by the primary router. [Bernard Aboba] Here is the proposed text: "The reachability test is performed by sending an ARP Request. The host SHOULD set the target protocol address (ar$tpa) to the IPv4 address of the default gateway being tested, and the sender protocol address field (ar$spa) to its own IPv4 address. The ARP Request SHOULD use the host's MAC address as the source, and the default gateway MAC address as the destination. The host includes its MAC address in the sender hardware address field (ar$sha), and sets the target hardware address field (ar$tha) to 0." [James Carlson] That looks pretty good. One question: are those "SHOULDs" correct (they're not "MUST"?)? If so, there might be a word or two about the considerations for ignoring the advice. [Bernard Aboba] The proposed resolution is as follows: In Section 1.2, delete the definitions of "ARP Probe" and "ARP Announcement". In the References, delete the reference to [ACD]. Change Section 2.2 to the following: "2.2. Reachability Test If the host has an operable routable IPv4 address on a MLN, a host conforming to this specification SHOULD perform a reachability test for that MLN, in order to confirm the configuration. The host skips the reachability test for a MLN if any of the following conditions are true: [a] The host does not have an operable routable IPv4 address on a MLN. In this case, the reachability test cannot confirm that the host has an operable routable IPv4 address, so completing the reachability test would serve no purpose. A host MUST NOT use the reachability test to confirm configuration of an IPv4 Link-Local address. [b] The host does not know the default gateway(s) on a MLN. In this case, insufficient information is available to carry out the reachability test. [c] If secure detection of network attachment is required. The reachability test utilizes ARP which is insecure, whereas DHCPv4 can be secured via DHCPv4 authentication, described in [RFC3118]. See Section 5 for details. For a particular MLN, the host MAY test the reachability of the primary default gateway, or it MAY test reachability of the primary and secondary default gateways in series or in parallel. In order to ensure configuration validity, the host SHOULD only configure default gateway(s) which pass the reachability test. In situations where more than one network is available on a given link, and more than one reachability test is performed in parallel, potentially with an attempt to obtain IPv4 configuration via DHCPv4, it is possible for the host to confirm more than one configuration. In this case, a DNAv4 implementation SHOULD prefer the configuration provided via DHCPv4. 2.2.1. Packet Format The reachability test is performed by sending an ARP Request. The host MUST set the target protocol address (ar$tpa) to the IPv4 address of the default gateway being tested, and the sender protocol address field (ar$spa) to its own IPv4 address. The ARP Request MUST use the host's MAC address as the source, and the default gateway MAC address as the destination. The host includes its MAC address in the sender hardware address field (ar$sha), and sets the target hardware address field (ar$tha) to 0. If a valid ARP Reply is received, the MAC address in the sender hardware address field (ar$sha) in the ARP Reply is matched against the target hardware address field (ar$tpa) in the ARP Request, and the and the IPv4 address in the sender protocol address field (ar$spa) of the ARP Reply is matched against the target protocol address field (ar$tpa) in the ARP Request. If a match is found, then if the host has an operable routable IPv4 address on the matched network, the host continues to use that IPv4 address, subject to the lease re- acquisition and expiration behavior described in [RFC2131], Section 4.4.5. The risk of an address conflict is greatest when the host moves between private networks, since in this case the completion of Duplicate Address Detection on the former network does not provide assurance against an address conflict on the new network. Until a host with a private address has confirmed the operability of its IPv4 configuration, it SHOULD NOT respond to ARP Requests, and SHOULD NOT broadcast ARP Requests containing its address within the sender protocol address field (ar$spa). However, where the host has an operable routable non-private address on a MLN, it MAY send ARP Requests using its address within the sender protocol address field (ar$spa) prior to confirming its IPv4 configuration, and MAY respond to ARP Requests. Sending an ICMP Echo Request [RFC792] to the default gateway IPv4 address does not provide the same level of assurance since where the host has moved between two private networks, an ICMP Echo Request can result in an ICMP Echo Response even when the default gateway has changed, as long as the IPv4 address remains the same. This can occur, for example, where a host moves from one home network using prefix 192.168/16 to another one. In addition, if the ping is sent with TTL > 1, then an ICMP Echo Response can be received from an off- link gateway. As a result, if the MAC address of the default gateway is not checked, the host can mistakenly confirm attachment to a MLN, potentially resulting in an address conflict. In addition, if the ICMP Echo Request results in a broadcast ARP Request being sent with the host's IPv4 address in ar$spa, this can result in ARP cache pollution. As a result, sending an ICMP Echo Request SHOULD NOT be used as a substitute for the DNAv4 procedure. If the initial ARP Request does not elicit a response, the host waits for REACHABILITY_TIMEOUT. Where IPv4 address acquisition occurs in parallel, the host MAY retransmit; otherwise the host SHOULD move on to the IPv4 address acquisition phase. If a valid ARP Reply is received, but cannot be matched against known networks, the host assumes it does not have an operable IPv4 configuration."
Proposed Resolution: Accept
Issue 25: Link Up Not Defined
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: May 23, 2005
Reference:
Document: DNA-11
Comment type: T
Priority: S
Section: 1.2
Rationale/Explanation of issue:
Recently, in a liaison letter from IEEE 802.21, some questions were raised
about the use of the terms "Link Up" and "Link Down".
To ensure we had this right in in the DNA document, I went in search of
definitions
of these terms. However, I could not find a definition in the following
documents:
http://www.ietf.org/internet-drafts/draft-ietf-dhc-dna-ipv4-11.txt
http://www.ietf.org/internet-drafts/draft-ietf-dna-link-information-01.txt
http://www.ietf.org/internet-drafts/draft-ietf-dna-goals-04.txt
http://www.ietf.org/internet-drafts/draft-ietf-dna-soln-frame-00.txt
http://www.watersprings.org/pub/id/draft-yamamoto-dna-term-00.txt
This struck me as more than a little odd, particularly when I found myself
asking basic questions about the meaning of these terms.
For example, in wireless communications link quality can be highly
transient; when multi-path interference is present, the S/N ratio can dip
20-30 dB within the space of a few feet.
In a wired network, the "up" link state is one exhibiting very low
frame loss, whereas the "down" state is one exhibiting 100 percent loss.
It is therefore clear when a link transitions from "down" to "up"; a
"Link Up" event is sent upon this transition. Similarly, it is clear
when a link transitions from "up" to "down" and a "Link Down" event
is sent upon this transition.
However, on a wireless network, intermediate frame loss rates are often
observed, so that links may be neither "up" nor "down" according to the
idealized definition. In this case, when are "Link Up" and "Link Down"
events sent?
Does the term "Link Up" refer to an event that only occurs when a link
has entered a link layer protocol state associated with the
initial ability to handle IP traffic? For example, within PPP does a
"Link Up" event only occur after the completion of IPCP negotiation?
Or in 802.11i, only after completion of the 4-way handshake?
Or can a "Link Up" event occur when a STA wanders out of range of an
access point, retransmits packets multiple times without a response,
scans, and then returns within range of the same AP, all without
changing state within the link layer state machine? In this scenario,
is a "Link Down" event also sent?
Similarly, does "Link Down" refer only to an event that occurs when a link
has entered a link layer protocol state that is not associated with the
ability to handle IP traffic? For example, in PPP a "Link Down" event
is presumably sent on receipt of an LCP-Terminate; in 802.11, a
Disassociate or Deauthenticate frame might trigger a "Link Down" event.
But can a "Link Down" event also be sent due to a transient decline in
link quality? For example, can this event be sent when a host wanders
out of range and retransmits a frame until it gives up? Or is a more
substantial outage required, affecting several distinct frames? In
other words, is a "Link Down" event, unlike a "Link Up" event, affected
by link quality?
I ask these questions because it seems to me that the precise definition
of these events may determine whether they are likely to be spurious, as
well as whether they arrive in a timely way.
For example, I have observed 802.11 NICs that will retransmit a lost frame
for >30 seconds after an AP is turned off before scanning for another
point of attachment. I have observed other NICs that will begin to scan
after two retransmissions.
[Jim Busse]
Historically, a lot of IETF documents use "link up" as triggers for other
events, without defining the meaning of "link up" state. Scary.
Sun defines the "link up" state on an ethernet device as the result of the
link meeting a basic set of tunable parameters. These statistics determine
when the Sun OS sets the "link up" state. Sun docs reprinted here without
permission....
"When auto-negotiation is enabled, the adv_*_cap statistics show which
capabilities are advertised to the link partner. When auto-negotiation is
disabled in forced mode, the statistics precisely show how a link should
function and that it must be matched on the link partner to achieve a valid
link up.
"The lp_cap_* parameters exist as kernel statistics for an Ethernet device.
The statistics are the advertised capabilities provided by the link partner
on completion of auto-negotiation. If the capabilities match the
capabilities provided in the local advertisement, the link can proceed to a
link up state. If no match is found, the link remains down. In two other
instances, lp_cap_* values might all be zero: when a cable is not present,
when forced mode is enabled."
Microsoft and Apple may have similar definitions, but I couldn't find any in
my MS references or on-line. I don't know how to look at Apple stuff...
:-(
There are a couple of instances of Link Up definition in other IETF docs,
but the definitions are pretty loose:
>From draft-pentland-dna-protocol-00.txt
DNAv6 assumes that the host's wireless link interface software and
hardware is capable of delivering a 'link up' event notification when
layer 2 on the host is configured and sufficiently stable for IP
traffic. "
Link down is not defined in that document.
>From draft-jung-mobileip-fastho-chain-00.txt
"two simple triggers of Layer 2 are required. One is the Link Up trigger.
MN or new AR receive the Link Up trigger when the MN arrives on the link
with the new AR. "
I'm not sure if the definition of "link up" and "link down" states are
within the scope of the DNA charter. I think the OS determines whether the
link is stable enough to perform the duties required by the OS, and is
therefore an OS construct, not a DNA construct.
[Tom Petch]
The terms have been in use by the IETF since at least RFC1157 (May 1990) and
while I have seen no formal definition in that or subsequent documents,
manufacturers have shown fair consensus on the meaning, about the ability to
send an IP packet. The beauty of IP being an unreliable network is linkUp tells
you nothing about what happens to the packet after it has left the box, only
that nothing stopped it leaving:-)
[Erik Nordmark]
If we are trying to solve the DNA issue, and ignore that hosts might
have multiple NICs, then we can come up with what we need operationally.
My take is that this should be sufficient:
They layer 2 probably has some internal set of states at which it is
known that no IP packets can be passed. Thus the loss probability is
100% due to the state at the driver/NIC/AP/whatever.
For DNAs purposes it is useful to get a 'link up' notification from L2
when L2 moves out of the state(s) where no IP packets are passed.
Likewise, if DNA needs a 'link down' notification, it is probably most
useful for DNA if that notification arrives when L2 moves from a state
where IP packets might be passed, to a state where they are guaranteed
to not pass. We do need to ensure that at least a 'link up' notification
is generated when the L2 connectivity changes, even if that change is
near instantaneous (quickly unplugging the Ethernet cable and plugging
one back in again; associating with an 802.11 AP even if the old AP was
believed to still be reachable).
With the above definitions we'll minimize what DNA would consider
spurious notifications just because of signal strength, yet never miss
the case when the layer 3 link is different.
That is the simple case.
Enter multihoming (multi-NICcing if you'd like)...
When a host has multiple NICs there might be any number of policy
related ways the host wants to choose. This could be based on a
combination of signal strength, "flakiness history", cost, and it might
be different for different applications running on the same host.
I think that is out of scope for DNA, but it probably makes sense to
explicitly mention it in the context of the L2 event notifications,
saying that the host implementation can benefit from finding out about
significant changes in signal strength, observed L2 retransmissions,
etc., as some of the inputs to the hosts policy choices.
[Bernard Aboba]
Sure, but I'd suggest that we should be clear that this additional info is
not a determinant of "Link Up" and "Link Down" events.
[Erik Nordmark]
Agree 100%.
[Alper Yergin]
http://www.ietf.org/internet-drafts/draft-ietf-dna-link-information-01.txt
We have the definitions as:
Node's establishment of a link-layer connection with an attachment
point that signifies the availability of IP service (i.e., being able
to send and receive IP packets) between the two is considered a link
up event.
Link down event signifies the discontinuation of the IP service
between the node and the attachment point. When the link-layer
connection is physically or logically torn down and it can no longer
carry IP packets, this is considered to be a link down event.
> Does the term "Link Up" refer to an event that only occurs when a link
> has entered a link layer protocol state associated with the
> initial ability to handle IP traffic?
Yes. This event should be associated with a state transition within the
L2. In the new state, the L2 should be willing to accept IP packets from
L3, and look for an opportunity to transmit them. (as opposed to
returning an immediate error message stating the request cannot be
fulfilled -- interface is down, IP service not available, etc.)
> For example, within PPP does a
> "Link Up" event only occur after the completion of IPCP negotiation?
> Or in 802.11i, only after completion of the 4-way handshake?
Yes and yes, as we stated in the dna-link-info I-D.
> Or can a "Link Up" event occur when a STA wanders out of range of an
> access point, retransmits packets multiple times without a response,
> scans, and then returns within range of the same AP, all without
> changing state within the link layer state machine? In this scenario,
> is a "Link Down" event also sent?
I don't think so.
> Similarly, does "Link Down" refer only to an event that occurs when a link
> has entered a link layer protocol state that is not associated with the
> ability to handle IP traffic? For example, in PPP a "Link Down" event
> is presumably sent on receipt of an LCP-Terminate; in 802.11, a
> Disassociate or Deauthenticate frame might trigger a "Link Down"
event.
Yes, we covered those in the same I-D as well.
> But can a "Link Down" event also be sent due to a transient decline in
> link quality? For example, can this event be sent when a host wanders
> out of range and retransmits a frame until it gives up? Or is a more
> substantial outage required, affecting several distinct frames? In
> other words, is a "Link Down" event, unlike a "Link Up" event, affected
> by link quality?
Eventually a continued "low quality" may lead to the L2 deciding a state
change that leads to a "link down", but this is a L2 design and
implementation decision.
> For example, I have observed 802.11 NICs that will retransmit a lost frame
> for >30 seconds after an AP is turned off before scanning for another
> point of attachment. I have observed other NICs that will begin to scan
> after two retransmissions.
I think this is a L2 implementation issue. At what point the L2 decides
that it has lost its connection to an access network.
[Bernard Aboba]
Using Alper's definition as a starting point, here a proposed definition
of "Link Down" and "Link Up". What do people think?
Link Down
An event provided by the link layer that signifies that the link is
no longer capable of communicating IP packets.
Link Up
An event provided by the link layer that signifies that the link
has become capable of communicating IP packets.
[Brett Pentland]
Works for me. My only concern would be about what would happen if an L2
technology comes along that can move its attachment point without any
intermediate period of disconnection, perhaps through some out-of-band
pre-establishmment of the new connection (and it would be good if such a
technology did!).
Perhaps it would just be a matter of using these definitions, but
ensuring that a transition like above causes a matched pair of Link Down
/ Link Up events to be generated.
As an aside: for draft-pentland-dna-solution-00 we only really
considered Link Up, because that is the point at which the network
layer on that interface is able to take some action (sending an RS, in
this case, to find out what the Link Up means). Link Down is probably
useful for coordinating between multiple interfaces, as are some of
the events that might be able to be triggered by the intermediate
connectivity situations that you described, but that is outside the
scope of what we tried to achieve in the proposal.
[Erik Nordmark]
I think it would be good if the definitions would clarify that even if
the link layer on the host sees 100% packet loss for a short while, it
doesn't necessarily imply that a link down event should be generated.
(It presumably shouldn't be generated until the link layer abandons the
L2 association/connection/whatever.)
[Brett Pentland]
How about:
Link Down
An event provided by the link layer that signifies a state change
associated with the interface no longer being capable of
communicating IP packets.
Link Up
An event provided by the link layer that signifies a state change
associated with the interface becoming capable of communicating
IP packets.
[Erik Nordmark]
I think it would be good if the definitions would clarify that even if
the link layer on the host sees 100% packet loss for a short while, it
doesn't necessarily imply that a link down event should be generated.
(It presumably shouldn't be generated until the link layer abandons the
L2 association/connection/whatever.)
[Bernard Aboba] How about this:
"Link Down
An event provided by the link layer that signifies a state change
associated with the interface no longer being capable of
communicating IP packets. A Link Down event is only generated once
the link layer considers the link unusable; transient periods of
high frame loss are not sufficient. DNAv4 does not utilize "Link
Down" indications.
Link Up
An event provided by the link layer that signifies a state change
associated with the interface becoming capable of communicating IP
packets."
Proposed Resolution: Accept
Issue 26: IETF Last Call comments
Submitter name: JinHyeock Choi
Submitter email address: jinchoe@samsung.com
Date first submitted: May 24, 2005 Reference:
Document: DNA-11
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:
I'd like to mention a few differences between DNA for IPv4 (DNAv4)
and DNA for IPv6 (DNAv6).
1. Abbreviation
For IPv4, DNA stands for "Detection of Network Attachment", whereas
for IPv6, DNA stands for "Detecting Network Attachment".
2. DNA Goal
I understand DNAv4 aims to detects movement (or lack of movement)
between subnets, and obtains (or continue to use) a valid IPv4 configuration.
DNAv6 aims to detect movement (or lack of movement) between links
to ascertain the validity of existing IP configuration but does not include
the actual IP configuration procedure.
3. Point of Attachment
In DNA mailing list, we define a term "Attachment Point", which represents
the link-layer connection.
For example, assume the case of two 802.11 b APs and a router on the same
ethernet link. Each AP is an Attachment Point and if a host moves from
one AP to another, it has moved to a different Attachment Point.
It's my impression that the "Attachment Point" from DNA WG and
"Point of Attachment" from the draft doesn't mean the same thing.
Also I am glad & relieved to see that the draft no longer includes the term
'link identifier'. Though the draft still uses the term 'link' a few times,
the meaning is clear from the context.
[Bernard Aboba]
> 1. Abbreviation
> For IPv4, DNA stands for "Detection of Network Attachment", whereas
> for IPv6, DNA stands for "Detecting Network Attachment".
We can change the title.
> 2. DNA Goal
> I understand DNAv4 aims to detects movement (or lack of movement)
> between subnets, and obtains (or continue to use) a valid IPv4 configuration.
>
> DNAv6 aims to detect movement (or lack of movement) between links
> to ascertain the validity of existing IP configuration but does not include
> the actual IP configuration procedure.
I think DNAv4 also ascertains the validity of an existing IP
configuration. If it is valid, then the host continues to use it. But if
it is not valid then the host needs to obtain a new configuration using
mechanisms outside of DNAv4 (e.g. DHCP). Is this different than DNAv6?
> 3. Point of Attachment
> In DNA mailing list, we define a term "Attachment Point", which represents
> the link-layer connection.
>
> For example, assume the case of two 802.11 b APs and a router on the same
> ethernet link. Each AP is an Attachment Point and if a host moves from
> one AP to another, it has moved to a different Attachment Point.
>
> It's my impression that the "Attachment Point" from DNA WG and
> "Point of Attachment" from the draft doesn't mean the same thing.
In the case above, the AP would also be called a "Point of Attachment".
> Also I am glad & relieved to see that the draft no longer includes the term
> 'link identifier'. Though the draft still uses the term 'link' a few times,
> the meaning is clear from the context.
I did get questions about the meaning of terms such as "link", "Link Up",
"Link Down" etc. I'll post all the terminology that is used
so that we can make sure we are consistent between DNAv4 and DNAv6.
[Bernard Aboba] The proposed resolution is as follows:
Replace Section 1.2 with the following:
"1.2. Terminology
This document uses the following terms:
ar$sha
ARP packet field: Source Hardware Address [RFC826]. The hardware
(MAC) address of the originator of an ARP packet.
ar$spa
ARP packet field: Source Protocol Address [RFC826]. For IP Address
Resolution this is the IPv4 address of the sender of the ARP
packet.
ar$tha
ARP packet field: Target Hardware Address [RFC826]. The hardware
(MAC) address of the target of an ARP packet.
ar$tpa
ARP packet field: Target Protocol Address [RFC826]. For IPv4
Address Resolution, the IPv4 address for which one desires to know
the hardware address.
ARP Probe
An ARP Request packet, broadcast on the local link, with an all-
zero 'sender IP address' (ar$spa). The 'sender hardware address'
(ar$sha) MUST contain the hardware address of the interface sending
the packet. The 'target hardware address' field (ar$tha) is
ignored and SHOULD be set to all zeroes. The 'target IP address'
(ar$tpa) field MUST be set to the address being probed.
ARP Announcement
An ARP Request packet, broadcast on the local link, identical to
the ARP Probe described above, except that both the sender (ar$spa)
and target (ar$tpa) IP address fields contain the IP address being
announced.
DHCP client
A DHCP client or "client" is an Internet host using the Dynamic
Host Configuration protocol (DHCP) [RFC2131] to obtain
configuration parameters such as a network address.
DHCP server
A DHCP server or "server" is an Internet host that returns
configuration parameters to DHCP clients.
Link A communication facility or medium over which network nodes can
communicate. Each link is associated with a minimum of two
endpoints. Each link endpoint has a unique link-layer identifier.
Link Down
An event provided by the link layer that signifies a state change
associated with the interface no longer being capable of
communicating IP packets. A Link Down event is only generated once
the link layer considers the link unusable; transient periods of
high frame loss are not sufficient. DNAv4 does not utilize "Link
Down" indications.
Link Layer
Conceptual layer of control or processing logic that is responsible
for maintaining control of the data link. The data link layer
functions provide an interface between the higher-layer logic and
the data link. The link layer is the layer immediately below IP.
Link Up
An event provided by the link layer that signifies a state change
associated with the interface becoming capable of communicating IP
packets.
Most Likely Attachment Network (MLAN)
The attached network heuristically determined by the host to be
most likely, based on hints.
Point of Attachment
The link endpoint on the link to which the host is currently
connected.
Routable address
In this specification, the term "routable address" refers to any
IPv4 address other than an IPv4 Link-Local address. This includes
private addresses as specified in [RFC1918].
Operable address
In this specification, the term "operable address" refers to either
a static IPv4 address, or an address assigned via DHCPv4 which has
not been relinquished, and whose lease has not yet expired.
Also, change "valid" to "operable" throughout the document (for compatibility with RFC 3927).
Proposed Resolution: Accept
Issue 27: GEN-ART Review
Submitter name: John
Loughney
Submitter email address: john.loughney@nokia.com
Date first submitted:
June 1, 2005
Reference:
Document: DNA-12
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:
2) Abstract says:
"The time required to detect movement (or lack of movement) ..." is a bit
strange. Do you need to detect lack of movement? I would imagine detecting
that the host is still attached is more relevant.
[BA] Agreed. How about this:
" The time required to detect movement between networks, and
to obtain
(or continue to use) an operable IPv4 configuration may be
significant as a fraction of the total handover latency in moving
between points of attachment. This document specifies a procedure
for optimizing detection of network attachment in order to decrease
the handover latency in moving between points of attachment."
3) Should add "Link Up" to a terminology section - there was discussion of what
link up means in the DNA working group, and I think that what the outcome was
in that wg should apply here.
[BA] How about this?
"Link Up
An event provided by the link layer that signifies a state change
associated with the interface becoming capable of communicating IP
packets."
4) Page 5 says:
"To improve robustness, this document suggests that hosts behave
conservatively with respect to assignment of IPv4 Link-Local
addresses, configuring them only in situations in which they can do .."
A reference to the IPv4 Link Local document would be useful here.
[BA] Agreed.
5) Bottom of page 15 says:
"Thus, associating to the same SSID is a necessary, but not .."
I think that you mean:
"Thus, associating to the same SSID is a necessity, but not .."
^^^
[BA] Propose removing that sentence since it doesn't seem to add value.
6) The security considerations section is a bit worrying. I'm
not sure
what should be added, but I don't think there is enough guidance to
implementors on how to deterimine if running DNA is safe or not. I'd
probably like some short text on this.
[BA] Here is a proposed rewrite of the security considerations section:
"Detecting Network Attachment for IPv4 (DNAv4) is based on ARP
and
DHCP and inherits the security vulnerabilities of these two
protocols.
ARP [RFC826] traffic is not secured, so that an attacker gaining
access to the network can spoof a response to the reachability test
described in Section 2.2, leading the querier to falsely conclude
that it is attached to a network that it is not connected to.
Similarly, where DHCPv4 traffic is not secured, an attacker could
masquerade as a DHCPv4 server, in order to convince the host that it
was attached to a particular network. This and other threats
relating to DHCPv4 are described in "Authentication for DHCP
Messages" [RFC3118].
The effect of these attacks will typically be limited to denial of
service, unless the host utilizes its IP configuration for other
purposes, such as security configuration or location determination.
For example, a host that disables its personal firewall based on
evidence that it had attached to a home network could be compromised
by spoofing of the DNAv4 reachability test. In general, adjustment
of the security configuration based on DNAv4 is NOT RECOMMENDED.
Hosts that depend on secure IP configuration SHOULD NOT use DNAv4,
but SHOULD instead utilize DHCP authentication [RFC3118], possibly in
combination with the Rapid Commit Option [RFC4039]."
Proposed Resolution: Accept
Issue 28: Silent RIP & OSPF
Submitter name: Sam
Hartman
Submitter email address: hartmans-ietf@mit.edu
Date first submitted:
June 21, 2005
Reference:
Document: DNA-12
Comment type: T
Priority: S
Section:
2.1
Rationale/Explanation of issue:
Section 2.1 of the document discusses implementations of DNAV4 using
snooping versions of OSPF and RIP to understand what prefixes are on a
subnet without fully participating in a routing protocol. While this
practice is encouraged by this specification, no reference to how to
do it is provided. If such a reference exists it needs to be
included. If no such reference exists, please confirm that sufficient
detail is provided that implementations are unlikely to break the
routing infrastructure by mis-implementing this feature.
[Margaret Wasserman]
Sam and I discussed this issue, and he asked whether this issue had been discussed in the WG.
I don't remember that it has, so I encouraged him to hold a discuss while we
discuss this...
Currently section 2.1 says:
Similarly hosts that support routing protocols such as RIP and OSPF
can use these protocols to determine the prefix(es) available on a
link and the default gateway(s) that serve those prefixes. Full
support is not required to glean this information. A host that
passively observes routing protocol traffic may deduce this
information without supporting a fully conformant routing protocol
implementation.
I know that snooping versions of RIP and OSPF are widely implemented and I
(think I) know what subsets are needed for this "passive observer"
functionality. This is trivial in RIP (you can literally act as a passive
observer on the RIP port), but a bit more complicated in OSPF, where (if I
understand correctly) you will have to associate with neighboring OSPF routers
to receive routing information, while not publishing any routes yourself. I
don't think that you can snoop OSPF information while being entirely passive,
can you?
Anyway, if there is a reference for how to snoop using OSPF or RIP, that would
be best. But, if there is not a reference, do you think that we need to say a
bit more in section 2.1 about what subsets of RIP and/or OSPF are needed to do
this?
As a minor editorial side note, you should probably include references for RIP
and OSPF.
[Bernard Aboba]
Silent RIP is discussed in RFC 1058, Section 3.1:
" There are provisions in the protocol to allow "silent" RIP
processes.
A silent process is one that normally does not send out any
messages.
However, it listens to messages sent by others. A silent RIP
might
be used by hosts that do not act as gateways, but wish to listen to
routing updates in order to monitor local gateways and to keep
their
internal routing tables up to date. (See [5] for a discussion
of
various ways that hosts can keep track of network topology.)
A
gateway that has lost contact with all but one of its networks
might
choose to become silent, since it is effectively no longer a
gateway."
Silent RIP has been widely implemented. See:
http://www.unix.org.ua/gated/node25.html
After searching the OSPF RFCs, I could not find a mention of "silent OSPF".
The proposed resolution is as follows:
In Section 2.1, delete the following paragraphs:
" Aside from utilizing link layer indications, a host may also be able
to utilize Internet layer information in order to determine the
MLAN.
IPv4 ICMP Router Discovery messages [RFC1256] provide information
relating to prefix(es) available on the link, as well as the
routers
that serve those prefix(es). A host may use ICMP Router
Discovery to
conclude that an advertised prefix is available; however it cannot
conclude the converse -- that prefixes not advertised are
unavailable.
However, since [RFC1256] is not widely implemented, it is NOT
RECOMMENDED that hosts utilize ICMP Router Discovery messages as an
alternative to the reachability test outlined in Section 2.2.
Instead, ICMP Router Advertisements can be used to obtain
information
on available prefixes and default gateway(s). This can
provide
additional resilience in the case where default gateway(s) become
unavailable.
Similarly hosts that support routing protocols such as RIP and OSPF
can use these protocols to determine the prefix(es) available on a
link and the default gateway(s) that serve those prefixes.
Full
support is not required to glean this information. A host
that
passively observes routing protocol traffic may deduce this
information without supporting a fully conformant routing protocol
implementation."
Add the following Section A.3 to Appendix A:
"A.3 Internet Layer Hints
Aside from utilizing link layer indications, a host may also be able
to utilize Internet layer information in order to determine the MLAN.
IPv4 ICMP Router Discovery messages [RFC1256] provide information
relating to prefix(es) available on the link, as well as the routers
that serve those prefix(es). A host may use ICMP Router Discovery to
conclude that an advertised prefix is available; however it cannot
conclude the converse -- that prefixes not advertised are
unavailable.
However, since [RFC1256] is not widely implemented, it is NOT
RECOMMENDED that hosts utilize ICMP Router Discovery messages as an
alternative to the reachability test outlined in Section 2.2.
Instead, ICMP Router Advertisements can be used to obtain information
on available prefixes and default gateway(s). This can provide
additional resilience in the case where default gateway(s) become
unavailable.
Similarly hosts that support routing protocols such as RIP [RFC2453]
can use these protocols to determine the prefix(es) available on a
link and the default gateway(s) that serve those prefixes. Full
support is not required to glean this information. A host that
passively observes routing protocol traffic may deduce this
information without supporting a fully conformant routing protocol
implementation. For a description of "Silent RIP", see [RFC1058]
Section 3.1."
Add the following references:
[RFC2453] Malkin., G., "RIP Version 2", RFC 2453, STD 56, November 1998.
[RFC1058] Hedrick, C., "Routing Information Protocol", RFC 1058, June 1988.
Proposed Resolution: Accept
Issue 29: Review
Submitter name: Thomas Narten
Submitter email address:
narten@us.ibm.com
Date first submitted:
June 22, 2005
Reference:
Document: DNA-12
Comment type: T
Priority: S
Section:
Various
Rationale/Explanation of issue:
I just reviewed this document, and overall I think its fine. Just some
nits (below).
But, stepping back, I'm trying to put my finger on what problem this
document actually solves. It doesn't change anything in the DHC spec
(i think). So is it just advice to implementations to be smarter than
they have been so far?
Is it to specifically point out stuff that existing implementations
just haven't done? but should be?
Is the win specifically:
- don't invoke DHC everytime you reattach, better to skip that? (does
this phase in practice cause long time outs)? Seems to me that dhc
shouldn't take that long in practice.
- is it mostly to fix broken behavior related to LL addresses and
giving up on DHC too soon?
- is it clarifying DHC issues (and if so, does it "update" the DHC
spec?) My sense is it doesn't do this.
or something else?
Or maybe, by how much time (roughly) does this reduce the "config"
process? Does it reduce it from one second to a couple hundred
milliseconds?
When we started this effort, I had a clear sense that things were
broken and could be made better. In the IPv6 case, I think I still see
that (i.e., waiting for RAs takes time, one has DAD, etc.) But for
IPv4, I'm less clear.
If we can summarize this, it might be good to add a paragraph to the
introduction. I.e., why its a no brainer to implement the spec.
Thomas
> ar$spa
> ARP packet field: Source Protocol Address [RFC826]. For IP Address
> Resolution this is the IPv4 address of the sender of the ARP
> packet.
s/source/sender/ (that is the terminology used in 826)
DNAv4 is used (in defn.) prior to definition. Perhaps define/use in
Introduction, e.g., "this document defines DNAv4, ...
> Most Likely Attachment Network (MLAN)
could be better acronym...
> Operable address
better called "candidate DNA address"? (not clear it is actually
"operable") or "previously assigned address"? Want the name to be
clear that the address is only a candidate of some sort, until the DNA
tests have completed...
Maybe "previously valid address"?
> If the reachability test is successful, the host MAY continue to use
> an operable routable IPv4 address without having to re-acquire it.
MAY??? what is the point of this spec if this is only a MAY?
> stored, the host makes an an educated guess of which network it has
s/an an/an/
s/of which/as to which/ ?
> in order to to confirm that it is connected to network on which it
s/to to/to/
s/to network/to an network/
> routable IPv4 address, so that completing the
s/that//
> 2.3. IPv4 Address Acquisition
>
> If the host has an operable routable IPv4 address on the MLAN but the
> reachability test fails, the host SHOULD verify the configuration
> by
s/verify/attempt to revalidate/ ??
> entering the INIT-REBOOT state, and sending a DHCPREQUEST to the
> broadcast address as specified in [RFC2131] Section 4.4.2.
[Thomas Narten]
> The document does point out problems in existing implementations, such as
> causing address collisions when moving between private networks.
Right. The advantages seem scattered throughout the document. What I
think would be good is to (in the introduction) have some sort of more
concrete explanation/motivation for why one should implement this.
How about changing paragraph two to something like:
This document synthesizes experience in the deployment of hosts
supporting ARP [RFC826], DHCP [RFC2131], and IPv4 Link-Local
addresses [RFC3927] to define a set of steps known as Detecting
Network Attachment (DNA). DNA optimizes the (common) case of
reattachment to a network that one has been connected to previously
by attemping to re-use a previous (but still valid) configuration
rather than go through the standard steps one invokes when
attaching to an network for the first time. Use of DNA can reduce
the reattachment time to a few milliseconds on common LANs. Since
this procedure is dependent on the ARP protocol, it is not suitable
for use on media that do not support ARP [RFC826].
> In IPv4 the protocols are not broken but implementations are often broken.
> For example, several VOIP phones do not do DHCP at all, they just roam and
> assume the address remains the same.
No comment. :-)
> Other implementaitons use ping and
> this causes address collions when they move from one private network to
> another. Others assign LLv4 addresses even when connecting to networks
> they had previously visited, on which they have a valid DHCP lease. The
> varieties of bad behavior vary considerably by implementation, but overall
> problems are very common.
Ok. It really is just saying "here's the best way to do things" taking
account of all the less-than-ideal things folks thought might make sense.
> > If we can summarize this, it might be good to add a paragraph to the
> > introduction. I.e., why its a no brainer to implement the spec.
> There is an Appendix devoted to performance issues, and this is also
> covered in the introduction. Perhaps some more material could be added
> describing the motivation for the work? I'd rather not get into what is
> wrong with specific implementations, though.
Hopefully the above text will do the trick.
> > > Most Likely Attachment Network (MLAN)
> >
> > could be better acronym...
> This is the term that we came up with after discussion on "most likely
> point of attachment" (MLPA). After deciding that an attachment point was
> an L2 concept, and that we would use the 802.221 definition of "link" the
> only term left to describe this was "network". Would MLN be better? MAN
> is already taken.
I can't help be read the acronym as M - "LAN", which it of course
isn't. I'd prefer MLN.
> >
> > > Operable address
> >
> > better called "candidate DNA address"? (not clear it is actually
> > "operable") or "previously assigned address"? Want the name to be
> > clear that the address is only a candidate of some sort, until the DNA
> > tests have completed...
> This is the term used in IPv4LL, and so we changed it for
consistency.
oh well. I mean, is it really too late to recall the IPv4LL RFC? :-)
> > Maybe "previously valid address"?
> >
> > > If the reachability test is successful, the host MAY continue to use
> > > an operable routable IPv4 address without having to re-acquire it.
> >
> > MAY??? what is the point of this spec if this is only a MAY?
> Would SHOULD be better? A MUST seems somewhat strong here.
SHOULD would be fine. This action is the crux of the spec, and it
seems weird for an optional spec to use MAY to highlight the main
action, IMO. If one doesn't want to do this step, why are they
implementing the spec at all...
[Bernard Aboba] The proposed resolution is as follows:
Accept the grammatical corrections.
Change the abstract to the following:
" The time required to detect movement between networks, and to obtain
(or continue to use) an IPv4 configuration may be significant as a
fraction of the total handover latency in moving between points of
attachment. This document synthesizes experience in the deployment
of hosts supporting ARP, DHCP, and IPv4 Link-Local addresses to
define a set of steps known as Detecting Network Attachment for IPv4
(DNAv4), in order to decrease the handover latency in moving between
points of attachment."
Change Section 1 to the following:
" The time required to detect movement between networks and to obtain
(or continue to use) an operable IPv4 configuration may be
significant as a fraction of the total handover latency in moving
between points of attachment.
This document synthesizes experience in the deployment of hosts
supporting ARP [RFC826], DHCP [RFC2131], and IPv4 Link-Local
addresses [RFC3927] to define a set of steps known as Detecting
Network Attachment for IPv4 (DNAv4). DNAv4 optimizes the (common)
case of reattachment to a network that one has been connected to
previously by attemping to re-use a previous (but still valid)
configuration, reducing the reattachment time to a few milliseconds
on LANs. Since this procedure is dependent on the ARP protocol, it
is not suitable for use on media that do not support ARP [RFC826]."
In Section 1.2, change the definitions of "ar$sha" and "ar$spa" to the
following:
"ar$sha
ARP packet field: Sender Hardware Address [RFC826]. The hardware
(MAC) address of the originator of an ARP packet.
ar$spa
ARP packet field: Sender Protocol Address [RFC826]. For IP Address
Resolution this is the IPv4 address of the sender of the ARP
packet."
In section 1.2 and elsewhere, change "MLAN" to "MLN":
Most Likely Network (MLN)
The attached network heuristically determined by the host to be
most likely, based on hints.
In Section 2.2, change the first paragraph to the following:
" If the host has an operable routable IPv4 address on the MLN, a host
conforming to this specification SHOULD perform a reachability test,
in order to confirm that it is connected to a network on which it has
an operable routable IPv4 address. If the reachability test is not
successful, the host proceeds to the IPv4 address acquisition phase,
described in Section 2.3."
Change Section 2.4 to the following:
"2.4. IPv4 Link-Local Addresses
To avoid inappropriate assignment of IPv4 Link-Local addresses, it is
recommended that hosts behave conservatively, assigning them only
when they can do no harm. As described in [RFC3927] Section 1.9, use
of a routable address is preferred when it is available:
2. If a host finds that an interface that was previously
configured with an IPv4 Link-Local address now has an operable
routable address available, the host MUST use the routable
address when initiating new communications, and MUST cease
advertising the availability of the IPv4 Link-Local address
through whatever mechanisms that address had been made known to
others.
Where the host does not have an operable routable IPv4 address on the
MLN, the host MAY configure an IPv4 Link-Local address prior to
entering the INIT state and sending a DHCPDISCOVER packet, as
described in [RFC2131] Section 2.3. However, should a routable IPv4
address be obtained, the IPv4 Link-Local address is deprecated, as
noted in [RFC3927] Section 1.9.
Where a host has an operable routable IPv4 address on the MLN, but
the DHCP client does not receive a response after employing the
retransmission algorithm, [RFC2131] Section 3.2 states that the
client MAY choose to use the previously allocated network address and
configuration parameters for the remainder of the unexpired lease.
Where a host can confirm that it remains connected to a network on
which it possesses an operable routable IPv4 address, that address
SHOULD be used, rather than assigning a IPv4 Link-Local address.
Since a IPv4 Link-Local address is often configured because a DHCP
server failed to respond to an initial query or is inoperative for
some time, it is desirable to abandon the IPv4 Link-Local address
assignment as soon as an IPv4 address lease can be obtained.
As described in [RFC3927] Appendix A, once a Link-Local IPv4 address
is assigned, existing implementations do not query the DHCPv4 server
again for five minutes. This behavior violates [RFC2131] Section
4.1:
The retransmission delay SHOULD be doubled with
subsequent retransmissions up to a maximum of 64 seconds.
Instead of waiting for five minutes, a DHCP client should continue to
retry every 64 seconds, even after allocating a IPv4 Link-Local
address. If the DHCP client succeeds in obtaining a routable
address, then the IPv4 Link-Local address is deprecated, as noted in
[RFC3927] Section 1.9.
Since it is inevitable that hosts will inappropriately configure IPv4
Link-Local addresses at some point, hosts with routable IPv4
addresses need to be able to respond to peers with IPv4 Link-Local
addresses, as per [RFC3927] Section 1.8. For example, a host
configured with a routable address may receive a datagram from a
link-local source address. In order to respond, the host will use
ARP to resolve the target hardware address and send the datagram
directly, not to a router for forwarding."
Proposed Resolution: Accept
Issue 30: Review of DNAv-13
Submitter name:
Stuart Cheshire
Submitter email address:
cheshire@apple.com
Date first submitted:
July 12, 2005
Reference:
http://www1.ietf.org/mail-archive/web/dhcwg/current/msg05188.html
Document: DNA-13
Comment type: T
Priority: S
Section:
Various
Rationale/Explanation of issue:
I just read draft-ietf-dhc-dna-ipv4-13.txt. I support the goals, but I think the current document misses the target. I have a long list of comments, but these are the three major ones: 1. Hints and heuristics It seems to me that the reliance on hints and heuristics is vastly overstated. The biggest and best heuristic of network attachment is the MAC address of the default gateway, which can be verified with a trivial ARP request (i.e. the proposed DNA mechanism itself), thereby negating much of the usefulness of all the other hints. The document even has a section for IP-layer hints, and then says they're pointless and shouldn't be used. Given than an ARP request can be answered in under 1ms, any hint or heuristic has to be significantly faster than that, or it's self-defeating.
[BA] I agree with Stuart that link layer hints may not be very useful. If the host attempts verification of multiple MLNs, then it is likely to be less sensitive to bad hints, and more likely to figure things out without any hints at all. This should be pointed out.
[Stuart]
The argument in Appendix A that you don't want to delay the normal DHCP
INIT-REBOOT process while waiting for DNA is bogus. There's no reason why
a host that wants rapid attachment to the network (which is, after all,
the whole point of DNA) wouldn't do both simultaneously, and then just
wait and see which approach yields a fruitful result quickest.
[BA] I agree that an implementation could choose to do both DHCP and
DNAv4 in parallel. This will be useful in circumstances where
hints are unreliable or the router may have gone down, or doesn't respond
for some reason. We should clarify this.
[Stuart]
2. Why only one MLN candidate?
Why limit a host to picking just one candidate network to verify?
The drafts says, "In the absence of other information, the MLN defaults
to the network to which the host was most recently attached." Consider a
laptop computer that moves daily between Ethernet at work and Ethernet at
home. If each time it picks its most recently attached as its best guess,
it's going to be wrong 100% of the time.
It would be much better if a device simply sent ten ARP Requests for the
last ten default gateway addresses it has seen, and then sees which, if
any, are answered.
If you don't want to hit the network with ten back-to-back wire-rate ARP
Requests, then they can be staggered 100ms apart, starting with the most
recently seen network, then the previous, and so on.
Most network gateways should be able to answer an ARP Request almost
instantaneously, since answering ARP Requests is something they have to
do all the time anyway, and if they're slow at that, then that would
adversely impact the performance of pretty much all IP traffic flowing
through the gateway.
This stream of ARP Requests would of course be going on concurrently with
DHCP INIT-REBOOT processing, and as soon as one of them yields a fruitful
result, the device should stop.
It's simple, it's fast, and it yields the desired result.
[BA] As Stuart points out, an
implementation can test reachability to
multiple MLNs in parallel. We should clarify that it is
ok for the implementation to do that. Assuming that the number of MLNs
chosen is reasonable, I don't think it's necessary to rate limit.
[BA] The proposed resolution is as follows:
In Section 1.2, change the definition of
MLN to:
"Most Likely Networks (MLNs)
The attached network(s) determined by the host to be most likely."
Change Section 2, 2.1, 2.2 and 2.3 to the following:
"2. Overview
DNAv4 consists of three phases: determination of the Most Likely
Networks (MLNs), reachability testing, and IPv4 address acquisition.
On connecting to a new point of attachment, the host responds to a
"Link Up" indication from the link layer by carrying out the DNAv4
procedure. Based on the networks that the host has most recently
connected to, as well as hints available from the link and Internet
layers, the host determines the "Most Likely Network(s)" (MLNs) and
determines whether it has an operable IPv4 configuration associated
with each of them.
If the host believes that it has an operable IPv4 configuration on a
MLN, it performs a reachability test in order to confirm that
configuration. The reachability test is designed to verify bi-
directional connectivity to the default gateway(s) on the MLN. If
the reachability test is successful, the host SHOULD continue to use
an operable routable IPv4 address, without needing to re-acquire it,
thereby allowing the host to bypass DHCPv4 as well as Duplicate
Address Detection (DAD). If the host believes that it has attached
to a network on which it has no operable IPv4 configuration, or if
the reachability test fails, then the host attempts to obtain an IPv4
configuration using DHCPv4.
Since DNAv4 represents a performance optimization, it is important to
avoid compromising robustness. In some circumstances, DNAv4 may
result in a host successfully verifying an existing IPv4
configuration where attempting to obtain configuration via DHCPv4
would fail (such as when the DHCPv4 server is down).
To improve robustness, this document suggests that hosts behave
conservatively with respect to assignment of IPv4 Link-Local
addresses [RFC3927], configuring them only in situations in which
they can do no harm. Experience has shown that IPv4 Link-Local
addresses are often assigned inappropriately, compromising both
performance and connectivity.
Where the host tests reachability only to a single MLN, the
performance of DNAv4 is to some extent dependent on the reliability
of the hints provided to the client. However, the host will
ultimately determine the correct IPv4 configuration even in the
presence of misleading hints. Where reachability test(s) fail a
timeout will occur, after which the host will eventually obtain the
correct configuration using DHCPv4, albeit with a performance
penalty.
Where there is more than one MLN, the host can test reachability to
the MLN(s) in serial or in parallel. An implementation can also
attempt to obtain IPv4 configuration via DHCPv4 in parallel with one
or more reachability tests, with the host using the first answer
returned. These optimizations reduce the reliance on link and
Internet layer hints, which may not be present or may be misleading.
Attempting to obtain IPv4 configuration via DHCPv4 in parallel is
particularly valuable in implementations that only test reachability
of a single MLN. Since confirming failure of a reachability test
requires a timeout, mistakes are costly and therefore sending a
DHCPREQUEST from the INIT-REBOOT state, as described in [RFC2131]
Section 3.2 and 4.3.2 may complete more quickly than the reachability
test.
DNAv4 does not increase the likelihood of an address conflict. The
DNAv4 procedure is only carried out when the host has an operable
IPv4 configuration on one or more MLNs, implying that duplicate
address detection has previously been completed. Restrictions on
sending ARP Requests and Responses are described in Section 2.2.1.
2.1. Most Likely Networks (MLNs)
In order to determine the MLN(s), it is assumed that the host saves
to stable storage parameters relating to the networks it connects to:
[1] The IPv4 and MAC address of the default gateway(s) on
each network.
[2] The link type, such as whether the link utilizes
Ethernet, or 802.11 adhoc or infrastructure mode.
[3] Link and Internet layer hints associated with each
network. For details, see Appendix A.
Appendix A discusses hints useful for the determination of the
MLN(s). By matching received hints against network parameters
previously stored, an implementation testing reachability to a single
MLN can make an an educated guess as to which network it has attached
to. Alternatively, an implementation that simultaneously tests
reachability to multiple MLNs can select them solely based on the
networks it has most recently connected to, in which case it may not
be necessary to consult hints.
2.2. Reachability Test
If the host has an operable routable IPv4 address on a MLN, a host
conforming to this specification SHOULD perform a reachability test,
in order to confirm that it is connected to a network on which it has
an operable routable IPv4 address.
The host skips the reachability test for a MLN if any of the
following conditions are true:
[a] The host does not have an operable routable IPv4
address on a MLN. In this case, the reachability
test cannot confirm that the host has an operable
routable IPv4 address, so completing the
reachability test would serve no purpose.
A host MUST NOT use the reachability test to
confirm configuration of an IPv4 Link-Local
address.
[b] The host does not have information on the default
gateway(s) on a MLN. In this case, insufficient
information is available to carry out the reachability
test.
[c] If secure detection of network attachment is required.
The reachability test utilizes ARP which is insecure,
whereas DHCPv4 can be secured via DHCPv4 authentication,
described in [RFC3118]. See Section 5 for details.
[d] If the default gateway address is an IPv4 Link-Local
address. In this case, it is possible that the
reachability test could be misinterpreted as
indication of an address conflict. See [RFC3927]
Section 2.2.1 for details.
For a particular MLN, the host MAY test the reachability of the
primary default gateway, or it MAY test reachability of the primary
and secondary default gateways in series or in parallel. In order to
ensure configuration validity, the host SHOULD only configure
default gateway(s) which pass the reachability test.
2.3. IPv4 Address Acquisition
If the host has an operable routable IPv4 address on one or more
MLNs, but the reachability test(s) fail, the host SHOULD attempt to
revalidate the configuration by entering the INIT-REBOOT state, and
sending a DHCPREQUEST to the broadcast address as specified in
[RFC2131] Section 4.4.2. As noted in Section 2, it is also possible
for IPv4 address acquisition to occur in parallel with the
reachability test.
If the host does not have an operable routable IPv4 address on any
MLN, the host enters the INIT state and sends a DHCPDISCOVER packet
to the broadcast address, as described in [RFC2131] Section 4.4.1.
If the host supports the Rapid Commit Option [RFC4039], it is
possible that the exchange can be shortened from a 4-message exchange
to a 2-message exchange.
If the host does not receive a response to a DHCPREQUEST or
DHCPDISCOVER, then it retransmits as specified in [RFC2131] Section
4.1.
As discussed in [RFC2131], Section 4.4.4, a host in INIT or REBOOTING
state that knows the address of a DHCP server may use that address in
the DHCPDISCOVER or DHCPREQUEST rather than the IPv4 broadcast
address. In the INIT-REBOOT state a DHCPREQUEST is sent to the
broadcast address so that the host will receive a response regardless
of whether the previously configured IPv4 address is correct for the
network to which it has connected.
Sending a DHCPREQUEST to the unicast address in INIT-REBOOT state is
not appropriate, since if the DHCP client has moved to another
subnet, a DHCP server response cannot be routed back to the client
since the DHCPREQUEST will bypass the DHCP relay and will contain an
invalid source address."
In Appendix A.1, add the following sentences to the fourth paragraph:
" In order to examine the tradeoffs in implementations that only test
reachability to a single MLN..."
Add the following sentence at the end of the section:
" If instead in the above example IPv4 address acquisition were carried
out simultaneously with the reachability test, then performance would
not suffer, even where hints are unreliable."
Proposed Resolution: Accept
Issue 31: Review of DNAv-14
Submitter name:
David Hankins
Submitter email address:
david_hankins@isc.org
Date first submitted:
August 9, 2005
Reference:
http://www1.ietf.org/mail-archive/web/dhcwg/current/msg05331.html
Document: DNA-14
Comment type: T
Priority: S
Section:
Various
Rationale/Explanation of issue:
Issue #1, a nitpick. The abstract and introductory words; This document synthesizes experience in the deployment I think Mr. Aboba meant;
This document synthesizes from experience in the deployment ^^^^ of hosts supporting ARP, DHCP, and IPv4 Link-Local addresses a set of steps known as Detecting Network Attachment for IPv4 ^ Note inclusion of 'from' and omission of 'to define'. Issue #2, ICMP Echo ARP cache pollution wording changes. Section 2.2.1, I liked the previous more vague description of the arp cache pollution threat from ICMP better. "It is bad, and you should learn why before you go and send an ICMP packet." There are at least two different kinds of ARP cache pollution that can happen, and the new description seems to have marginalized one of them, which annoyingly is the one I'm more worried about. Suffice to say, sending an ICMP echo request can result in ARP cache pollution on the default gateway in circumstances where you can predict the exchange WILL NOT result in an ARP request, much less one containing the host's IPv4 address in arp$spa, as the text now lists as mandatory for the condition to ocurr.
Consider the point of view of the default gateway receiving an ICMP
Echo Request packet.
In the case where the source IP address of the ICMP Echo Request packet
is in the local subnet, you have everything you need in headers to respond
right away. Why ARP request for the source MAC address of the ICMP Echo
Request?
So, the source MAC is shoved into the ARP cache to short circuit this.
When you send your response, you already know the requestor's ARP mapping
and can send the packet straight away without having to wait for a reply
back from ARP.
It's an ICMP optimization, but also has become a popular means for
"High Availability" clusters to change MACs associated with service
IP addresses without having to wait for the cache to time out.
I know from experience that at least Cisco models of the era I used
to network do this. I presume this is still the case today (a
grandfather IOS feature), and that many other routers probably do
the same.
I'm more worried about pollution on the default gateway's arp cache
than any other node on the network, so even if we had to choose between
which two of these pitfalls to describe, I still think the draft has
chosen the wrong one.
I don't think we want to get into a big discussion in exactly what
circumstances arp cache pollution may ocurr. I think the draft was
right the first time around in just saying "Sending an ICMP Echo
Request to the default gateway may result in ARP cache pollution."
If the IESG is pushing back on this, I think the only answer is an
appendix devoted to the problems with ICMP echo request. There are
many ways it can be made to go wrong, and the statement in the draft
currently is misleading to suggest it requires those pre-requisites
to fail.
I don't like that idea. It will take a lot of Mr. Aboba's time and I
don't think it will be really useful to the majority of implementers.
I'd rather it had stayed vague.
Issue #3, another wording nitpick.
Appendix A.1, "Then it only worth considering"...looks like an editing
error...you took out 'is' in -12 according to the diff. I think that
'is' belongs there.
Issue #4, ICMP Router Discovery influencing DNA?
Appendix A.3, I realize this text just moved, but now on my third reading
of these words (I think), I wonder at part of the meaning. Is this an
indication that default gateways learned via ICMP Router Discovery are
acceptable "Section 2" targets for DNA?
I hadn't thought about that dimension to these words. I don't have an
opinion yet, I just wanted to bring it under the WG's lens.
Issues 1 and 3 are just nitpicks. 4 needs more WG exposure I think.
I'm fairly concerned about 2. I think it can lead people into thinking
they can get away with a broken scenario ("You can do ICMP Echo if...").
[BA] Thanks for the comments. I've fixed the typos referred to in Issue 1 and 3, and restored the original text in Issue #2: http://www.drizzle.com/~aboba/DNA/draft-ietf-dhc-dna-ipv4-15.txt
With respect to Issue #4, I think the intent was for both L2 and L3 "hints" to be available to determine the MLN(s) to be subjected to the reachability test. Note that this is optional; if multiple MLN(s) are tested, then the host could ignore hints and just do the reachability test on the last N networks. So if an ICMP Router Advertisement is received, then it could cause a DNAv4 host to test reachability to the announced network. However this would require the host to have stored the parameters (Gateway IP & MAC address) necessary to carry out the test.
[David Hankins]
At some point, you'd think I'd learn to think about issues like #4 before rattling them off in email. Evidently not. Scratch it...after some thought, I was clearly over-reacting.
[Bernard Aboba]
So you're ok with leaving the text in DNAv4-14 as it is?
[David Hankins] Yes.
Proposed Resolution: Accept
Issue 32: Simplification of DNAv4It has been suggested that the DNAv4 specification can be simplified by
recommending that implementations simultaneously test reachability to
one or more networks in parallel with attempting to obtain a configuration
via DHCPv4. While the current specification allows this, it is optional
rather than recommended behavior, and so the specification still has to
accommodate the case where an implementation attempts to obtain configuration
serially.
By assuming that the implementation attempts to obtain configuration by
multiple mechanisms in parallel, it can be guaranteed that DNAv4 will
not take longer than DHCPv4 to obtain a configuration. It also simplifies
the DNAv4 client implementation, since the client can determine the set
of networks for which it has an operable configuration, and select a
subset of that for reachability testing without having to consider link
layer hints other than "link up".
For example, if a host has still-valid DHCP leases on three networks,
it can do 3 reachability tests in parallel with attempting to obtain
a configuration via DHCPv4.
The downside of this approach is the extra traffic. However, this risk can
be mitigated via rate limiting, jittering and exponential backoff.
Therefore, it appears to me that the benefits of this approach, in terms
of a simplified implementation and improved performance and robustness
are worth the costs.
Here are the proposed changes:
Section 1.2:
Delete the definition of "Most Likely Network" and replace this everywhere
in the document with "network". Since it is now recommended that the DNAv4
host do a reachability test on a subset of the networks with operable
configurations, the host no longer has to worry about which networks are
"most likely", it can just test all of them.
Section 2:
Change the text to the following:
"2. Overview
On connecting to a new point of attachment, the host responds to a
"Link Up" indication from the link layer by carrying out the DNAv4
procedure.
For each network that it connects to, it is assumed that the host
saves to stable storage the following parameters:
[1] The IPv4 and MAC address of the default gateway(s)
[2] The IPv4 configuration parameters, including
the assigned address and lease expiration time
From the set of networks which have operable IPv4 address(es)
associated with them, the host selects a subset, and attempts to
confirm the configuration for each network, using the reachability
test described in Section 2.1.
If the reachability test is successful, verifying bi-directional
connectivity to the default gateway(s), the host SHOULD continue to
use the operable routable IPv4 address associated with the confirmed
network, without needing to re-acquire it, allowing the host to
bypass Duplicate Address Detection (DAD).
If a DHCPv4 client is operational, it is RECOMMENDED that the host
attempt to obtain IPv4 configuration via DHCPv4 in parallel with the
reachability tests, with the host using the first answer returned.
This ensures that the DNAv4 procedure will not result in additional
delay in the case where reachability test(s) fail, or where sending a
DHCPREQUEST from the INIT-REBOOT state, as described in [RFC2131]
Section 3.2 and 4.3.2 completes more quickly than the reachability
test(s).
DNAv4 does not increase the likelihood of an address conflict. The
reachability test is only carried out for a network when the host has
previously completed duplicate address detection and obtained an
operable IPv4 configuration on that network. Restrictions on sending
ARP Requests and Responses are described in Section 2.1.1."
Delete Section 2.1 and replace Section 2.2 with the following:
"2.1. Reachability Test
The host skips the reachability test for a network if any of the
following conditions are true:
[a] The host does not have an operable routable IPv4
address on that network. In this case, the reachability
test cannot confirm that the host has an operable
routable IPv4 address, so completing the
reachability test would serve no purpose.
A host MUST NOT use the reachability test to
confirm configuration of an IPv4 Link-Local
address or a statically assigned IPv4 address.
[b] The host does not know the default gateway(s) on
that network. In this case, insufficient information
is available to carry out the reachability test.
[c] If secure detection of network attachment is required.
The reachability test utilizes ARP which is insecure.
For a particular network, the host MAY test reachability to the
primary default gateway, or it MAY test reachability to both the
primary and secondary default gateways, in series or in parallel. In
order to ensure configuration validity, the host SHOULD only
configure default gateway(s) which pass the reachability test.
In situations where more than one network is available on a given
link, or the network configuration has changed, it is possible for
the host to confirm more than one configuration. For example, it is
possible that one or more reachability test(s) succeed, and in
addition, configuration is provided via DHCPv4. In this case, a
DNAv4 implementation SHOULD prefer the configuration provided via
DHCPv4."
Replace the last paragraph of Section 2.2.1 (now 2.1.1) with the following:
"In order to prevent synchronization, ARP Requests are delayed by a
random interval uniformly distributed on 0 to JITTER_INTERVAL. If
the initial ARP Request does not elicit a response, the host waits
for REACHABILITY_TIMEOUT. The timeout value is doubled with each
retransmission. It is RECOMMENDED that a host retransmit no more
than twice. To provide damping in the case of spurious "Link Up"
indications, it is recommended that the DNAv4 procedure be carried
out no more than once a second."
Delete the first two paragraphs of Section 2.3 (now 2.2). Add the following sentence to Section 3: "The default value of JITTER_INTERVAL is 120ms." Delete Appendix A and all the references it cites.
Proposed Resolution: Accept
Issue 33: Clarification of DHCP Interaction
Submitter name: James Carlson
Submitter email address: james.d.carlson@sun.com
Date first submitted: October 12, 2005
Reference:
Document: DNA-16
Comment type: T
Priority: S
Section: 2.1
Rationale/Explanation of issue:
In Section 2.1, change:
"In situations where more than one network is available on a given
link, or the network configuration has changed, it is possible for
the host to confirm more than one configuration. For example, it is
possible that one or more reachability test(s) succeed, and in
addition, configuration is provided via DHCPv4. In this case, a
DNAv4 implementation SHOULD prefer the configuration provided via
DHCPv4."
To:
"In situations where both DNAv4 and DHCP are used on the same link, it
is possible that the reachability test will complete successfully,
and then DHCP will complete later with a different result. If this
happens, the implementation SHOULD abandon the reachability test
results and use the DHCP result instead.
Note that it's not possible to get more than one reachability test
response on a given link, because the first one is the only one that
should be accepted. Once a valid reachability test response is
received, validation is complete, and additional responses (if any)
should be discarded."
Proposed Resolution: Accept
Issue 34: Use of DNA with IPv4LL and Static
Addresses
Submitter name: Stuart Cheshire
Submitter email address: cheshire@apple.com
Date first submitted: October 12, 2005
Reference:
Document: DNA-16
Comment type: T
Priority: S
Section: 2.1, 2.3
Rationale/Explanation of issue:
In Section 2.1 Delete:
"A host MUST NOT use the reachability test to
confirm configuration of an IPv4 Link-Local
address or a statically assigned IPv4 address."
In Section 2.3, delete:
" As described in [RFC3927] Appendix A, once a Link-Local IPv4 address
is assigned, existing implementations do not query the DHCPv4 server
again for five minutes. This behavior violates [RFC2131] Section
4.1:
The retransmission delay SHOULD be doubled with
subsequent retransmissions up to a maximum of 64 seconds.
Instead of waiting for five minutes, a DHCP client should continue to
retry every 64 seconds, even after allocating a IPv4 Link-Local
address. If the DHCP client succeeds in obtaining a routable
address, then the IPv4 Link-Local address is deprecated, as noted in
[RFC3927] Section 1.9."
Add:
"DNAv4 applies only to previously-configured addresses that had some
lease lifetime associated with them, during which lifetime the
address may be legitimately regarded as being reserved for exclusive
use by the assigned host. DHCP-assigned addresses fit this
description, as do manually-assigned addresses, which can be treated
as equivalent to DHCP-assigned addresses with an infinite lifetime.
IPv4 Link-Local address [RFC3927] do not fit this description, since
IPv4 Link-Local addresses are not handed out by an authoritative
server, and do not come with any guaranteed usable lifetime. A
host's claim on an IPv4 Link-Local address is valid only as long as
that host remains connected to the link, actively defending against
probes for its chosen address. As soon as a host shuts down, sleeps,
or otherwise disconnects from a link, it immediately relinquishes any
claim it may have had on any IPv4 Link-Local address on that link. A
host wishing to reclaim a previously-used IPv4 Link-Local address
MUST perform the full probing and annoucement process required by
[RFC3927], and MUST NOT attempt to use DNAv4 as a shortcut to bypass
that process."
[Bernard Aboba]
With respect to use of DNAv4 with manually configured IP addresses, I have
a question. What if an address is manually configured on a network with a
DHCP server, but at the time it was assigned, no address conflict existed?
DAD completes, and the manually assigned address is used. Then the host
comes back to the network and uses DNAv4 to reconfirm the configuration.
However, meanwhile the DHCP server has assigned the address, so a conflict
now exists.
A similar situation occurs with a NAT/DHCP server with no stable storage,
which could allocate the same address after rebooting/crashing.
The proposed resolution is as follows:
Change Section 2.3 to the following:
"2.3. IPv4 Link-Local Addresses
DNAv4 applies only to previously-configured addresses that had some
lease lifetime associated with them, during which lifetime the
address may be legitimately regarded as being reserved for exclusive
use by the assigned host. DHCP-assigned addresses fit this
description, but IPv4 Link-Local address [RFC3927] do not, since IPv4
Link-Local addresses are not handed out by an authoritative server,
and do not come with any guaranteed usable lifetime.
A host's claim on an IPv4 Link-Local address is valid only as long as
that host remains connected to the link, actively defending against
probes for its chosen address. As soon as a host shuts down, sleeps,
or otherwise disconnects from a link, it immediately relinquishes any
claim it may have had on any IPv4 Link-Local address on that link. A
host wishing to reclaim a previously-used IPv4 Link-Local address
MUST perform the full probing and announcement process required by
"Dynamic Configuration of IPv4 Link-Local Addresses" [RFC3927], and
MUST NOT attempt to use DNAv4 as a shortcut to bypass that process.
Where the host does not have an operable routable IPv4 address on any
network, the host MAY configure an IPv4 Link-Local address prior to
entering the INIT state and sending a DHCPDISCOVER packet, as
described in Section 2.3 of the DHCP specification [RFC2131]. Where
a host can confirm that it remains connected to a network on which it
possesses an operable routable IPv4 address, that address should be
used and the IPv4 Link-Local address is deprecated, as noted in
Section 1.9 of the IPv4 Link-Local specification [RFC3927].
Where a host has an operable routable IPv4 address on one or more
networks, but the reachability test cannot confirm the configuration
and the DHCPv4 client does not receive a response after employing the
retransmission algorithm, Section 3.2 of the DHCP specification
[RFC2131] states that the client MAY choose to use the previously
allocated network address and configuration parameters for the
remainder of the unexpired lease."
Add Section 2.4:
"2.4. Manually Assigned Addresses
An implementation may use DNAv4 to confirm the configuration of
manually assigned addresses. However, special consideration is
required for this to produce reliable results, so that it SHOULD NOT
be enabled by default.
For the purposes of DNAv4, manually assigned addresses may be treated
as equivalent to DHCP-assigned addresses with an infinite lifetime.
This does not significantly increase the probability of an address
conflict as long as the manually assigned address is reserved by the
DHCP server or is outside the scope of addresses assigned by a DHCP
server. However, where the manually assigned address is within an
address scope utilized by a DHCP server, it is possible that the host
will be unavailable when the DHCP server checks for a conflict prior
to assigning the conflicting address. In this case, a host utilizing
DNAv4 could confirm an address that had been assigned to another
host.
Typically an address is manually assigned on a network because a
dynamically assigned address was not suitable for some reason.
Therefore where both DNAv4 and DHCP are run in parallel and DNAv4
confirms a manual configuration, it may be undesirable to allow this
configuration to be overridden by DHCP, as described in Section 2.1.
However, packet loss may cause the reachability test to fail while
DHCP completes successfully, resulting in the host obtaining a
dynamic address where a static address is desired. In order to
provide for reliable reconfirmation of manually assigned addresses,
reachability tests for manual configurations require a more
aggressive retransmission strategy than that detailed in Section 4.1
of the DHCP specification [RFC2131]. For example, shorter
retransmission intervals and more persistent retransmissions may be
required."
Proposed Resolution: Accept
Issue 35: Use of DNAv4 with non-gateway targets
Submitter name: James Carlson
Submitter email address: james.d.carlson@sun.com
Date first submitted: October 12, 2005
Reference:
Document: DNA-16
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:
As discussed with Bernard Aboba and the other authors, I feel that
this document ends up being a bit clearer and more general if the
references to "default gateways" are removed. Though it's certainly
the case that many nodes do, there's no necessary reason that any IP
node must have a default gateway, and on networks where there isn't
such a gateway, the current draft makes it appear as though "only"
default routes need apply.
In fact, any test address on the network will serve the purpose,
though it seems likely that the best choice is to probe a local
router.
The changes below reflect that rewording. I realize that time has
already run out for this draft, so if the consensus is to publish
as-is rather than consider any rewording, I'm happy enough with that.
--- dnav4.txt Wed Oct 12 08:17:12 2005
+++ dnav4-new.txt Wed Oct 12 08:23:57 2005
@@ -199,19 +199,20 @@
following parameters:
.nf
- [1] The IPv4 and MAC address of the default gateway(s)
+ [1] The IPv4 and MAC address of one or more other
+ ("test") nodes on the network.
[2] The IPv4 configuration parameters, including
the assigned address and lease expiration time
.fi
From the set of networks which have operable IPv4 address(es)
associated with them, the host selects a subset, and attempts
to confirm the configuration for each network, using
the reachability test described in Section 2.1.
If the reachability test is successful, verifying bi-directional
-connectivity to the default gateway(s),
+connectivity to the test nodes,
the host SHOULD continue to use the operable routable
IPv4 address associated with the confirmed network, without
needing to re-acquire it, allowing the host to bypass Duplicate
@@ -252,7 +253,7 @@
confirm configuration of an IPv4 Link-Local
address or a statically assigned IPv4 address.
-[b] The host does not know the default gateway(s) on
+[b] The host does not know the address of any test node on
that network. In this case, insufficient information
is available to carry out the reachability test.
@@ -260,13 +261,15 @@
The reachability test utilizes ARP which is insecure.
.fi
-For a particular network, the host MAY test reachability
-to the primary default gateway, or it MAY test reachability
-to both the primary
-and secondary default gateways, in series or in parallel.
+For a particular network, the host SHOULD use the addresses of
+local routers (preferably default gateways) as its test nodes,
+although any address on the target network will suffice. If more than
+one address is known, those addresses may be tested in series or in
+parallel.
In order to ensure configuration
-validity, the host SHOULD
-only configure default gateway(s) which pass the reachability test.
+validity, the host SHOULD
+only configure routes for which the next hop address passes the
+reachability test. Other routes SHOULD be re-learned.
In situations where more than one network is available on a given link,
or the network configuration has changed,
@@ -283,10 +286,10 @@
.in +0.3i
The reachability test is performed by sending an ARP Request.
The host MUST set the target protocol address (ar$tpa) to the
-IPv4 address of the default gateway being tested, and the sender protocol
+IPv4 address of the address being tested, and the sender protocol
address field (ar$spa) to its own IPv4 address.
The ARP Request MUST use the
-host MAC address as the source, and the default gateway MAC
+host MAC address as the source, and the test node MAC
address as the destination. The host includes its MAC address
in the sender hardware address field
(ar$sha), and sets the target hardware address field (ar$tha)
@@ -315,7 +318,7 @@
to confirming its IPv4 configuration, and MAY respond to ARP
Requests.
-Sending an ICMP Echo Request [RFC792] to the default gateway IPv4
+Sending an ICMP Echo Request [RFC792] to an IPv4
address does not provide the same level of assurance since this may
require an ARP Request/Reply exchange. Where the host has moved
between two private networks, this could result in ARP cache
@@ -322,13 +325,13 @@
pollution.
Where a host moves from one private network to another, an ICMP Echo
-Request can result in an ICMP Echo Response even when the default
-gateway has changed, as long as the IPv4 address remains the same.
+Request can result in an ICMP Echo Response even when the MAC
+address has changed, as long as the IPv4 address remains the same.
This can occur, for example, where a host moves from one home
network using prefix 192.168/16 to another one. In addition, if the
ping is sent with TTL > 1, then an ICMP Echo Response can be received
from an off-link gateway. As a result, if the MAC address of the
-default gateway is not checked, the host can mistakenly confirm
+test node is not checked, the host can mistakenly confirm
attachment, potentially resulting in an address conflict.
As a result, sending of an ICMP Echo Request SHOULD NOT be used as a
substitute for the reachability test.
[Bernard Aboba]
In DNAv4, the "network anchor" identities are defined to include both the IP address and the MAC address, so that duplication of both would be required to cause confusion. This works as long as the "network anchor" is actually an anchor, not a buoy -- it cannot also be mobile. [Erik Nordmark]
Can't it be confused in other cases? Suppose I have a server with VLAN support that is part of multiple VLANs. The server uses the same MAC address on all its VLANs as is normal with VLAN capable network interfaces. Suppose in addition the multiple VLANs are separate private address space domains - all using 10.0.0.0/8 addresses. Now the server can have the same IP address on all its VLANs as well (presumably requires running Xen or vmvare on the server to make sure the server doesn't get confused). Thus on VLAN 1 the server has MAC address M1 and IP address 10.1.2.3. The default routers on VLAN1 are 10.0.0.1 and 10.0.0.2. On VLAN 2 the server has MAC address M1 and IP address 10.1.2.3. The default routers on VLAN2 (different than on 1) are 10.0.1.1 and 10.0.1.2. In this case the fact that MAC address M1 can be reached at IP address 10.1.2.3 does not mean that the IP configuration is the same; the host needs to get the different default routers when moving between the links.
[Erik Nordmark]
I don't have a problem with the desire to generalize things to not assume routers, but the devil is in the proverbial details. > +For a particular network, the host SHOULD use the addresses of > +local routers (preferably default gateways) as its test nodes, > +although any address on the target network will suffice. As somebody else pointed out, you can't select any address as a test one, since that node might be mobile as well. So having the PDA in my left pocket pick the IP+MAC of the PDA in my right pocket would be catastrophic, since both of them are likely to move at the same time. So we should change the above to > +For a particular network, the host SHOULD use the addresses of > +local routers (preferably default gateways) as its test nodes, > +although any address on the target network that is know to not be moving around will suffice. This leads to the question of how can a host determine which test address can be safely used short of manual configuration. If this is the case I think we should make this explicit in the document, for instance by saying: Unless the the host has been manually configured with a test node, or otherwise knows a test node which is it certain is not mobile, the host should select the default router(s) as the test node(s).
[BA] Given the issues above, the proposed resolution is to accept the changes,
with the exception of the sentence that suggests that any test node can be
used. At the moment, I do think we are clear enough about all the implications
of this.
Proposed Resolution: Accept
Issue 36: Problem Statement
Submitter name: Stuart Cheshire
Submitter email address: cheshire@apple.com
Date first submitted: October 12, 2005
Reference:
http://www1.ietf.org/mail-archive/web/dhcwg/current/msg05497.html
Document: DNA-16
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:
I think the newly pared-down draft is a vast improvement.
One of the things I found myself thinking, as I read various revisions of
this specification over the last few months, is that it didn't clearly
describe exactly what problem it was trying to solve, and why, and what
constraints this implied for the possible solution space.
In the IETF spirit of "provide text", I offer a first cut at this
analysis and discussion, below.
One surprising conclusion came to me as I was writing this:
All along, I'd thought that the point of this work was to eliminate the
seven-second delay for address conflict detection; to turn a wait for a
non-response, which can't be shortened, into a wait for a positive
acknowledgement from the router, which *can* be made almost arbitrarily
fast, within the limits of the speed of light.
However, it turns out (I think) that this is not true. Any candidate
configuration eligible for DNAv4 is also eligible for DHCP INIT-REBOOT,
and INIT-REBOOT does *not* require that the client perform address
conflict detection. Thus, all that DNAv4 is accelerating is the DHCP
INIT-REBOOT REQUEST/ACK cycle.
See proposed text below:
[Section Number xxx] Goals and Constraints
DHCP is an effective and widely adopted mechanism for a host to
obtain an IP address for use on a particular network link, or to
re-validate a previously obtained address via DHCP's INIT-REBOOT
mechanism [RFC2131].
In the case of obtaining a new address, DHCP specifies that the
client SHOULD use ARP to verify that the offered address is not
already in use. The process of address conflict detection [ACD] can
take as much as seven seconds. In principle this time interval could
be shortened, with the obvious trade-off: the less time a host spends
waiting to see if another host is already using its intended address,
the greater the risk of inadvertent address conflicts.
In the case of re-validating a previously obtained address using the
INIT-REBOOT mechanism, the DHCP specification does not require the
client to perform address conflict detection, so this seven-second
delay does not apply. However, the DHCP server may be slow to
respond, or may be down and not responding at all, so hosts could
benefit from having an alternative way to quickly determine that a
previously obtained address is valid for use on this particular link.
The alternative mechanism specified by this document applies when a
host has a previously-allocated DHCP address, which was not returned
to the DHCP server via a DHCP RELEASE message, and which still has
time remaining on its lease. In this case, the host may determine
whether it has re-attached to the logical link where this address is
valid for use, by sending a unicast ARP Request packet to the default
router previously known for that link (or in the case of a link with
more than one router, by sending one or more unicast ARP Request
packets to one or more of those routers).
The use of unicast ARP has a number of benefits. One benefit is that
unicast packets impose less burden on the network than broadcast
packets, particularly on 802.11 networks where a 54Mb/sec 802.11g
link may have to slow down to 1Mb/sec to send a broadcast packet.
Another benefit is that in the event of the host not being on the
link it hoped to find itself on, a broadcast ARP Request could
pollute the ARP caches of peers on that link. When using private
addresses [RFC1918] another device could be legitimately using the
same address, and a broadcast ARP Request could disrupt its
communications, causing TCP connections to be broken, and similar
problems. By using a unicast ARP packet instead, addressed to the MAC
address of the router the host is expecting to find, if the host is
not on the expected link, then there will be no device with that MAC
address, and the ARP packet will harmlessly disappear into the void
without doing any damage.
These issues that define the applicability of DNAv4 lead us to a
number of conclusions:
o DNAv4 is a performance optimization. Its purpose is to take a
process that is already quite fast (DHCP INIT-REBOOT) and make
it faster.
o As a performance optimization, it must not sacrifice correctness.
In other words, false positives are not acceptable. DNAv4 must not
conclude that a host has returned to a previously-visited link
where it has an operable IP address if this is not in fact the
case.
o As a performance optimization, false negatives are acceptable.
It is not an absolute requirement that this optimization correctly
recognize a previously-visited link in all possible cases.
For example, if a router ignores unicast ARP Requests then DNAv4
will not be able to detect that it has returned to the same link
in future. This is acceptable because it does not affect
correctness. In this case the host still operates correctly, as it
did before in a world without DNAv4; it just operates without the
performance benefit of DNAv4. Users and network operators who
desire the performance improvement offered by DNAv4 will have an
incentive to upgrade their router to one that supports DNAv4.
o As a performance optimization, DNAv4 should not have an adverse
effect compared to today's status quo. In cases where DNAv4 fails
to provide a benefit, it should add little or no delay compared to
today's existing DHCP INIT-REBOOT processing. The practical effect
of this statement is that DHCP INIT-REBOOT processing needs to
proceed in parallel with DNAv4 processing. In particular, waiting
for DNAv4 to fail before beginning DHCP processing has the
potential to make an operation that is currently very quick into an
operation that takes dramatically longer, which would be the exact
opposite of the desired effect of this performance optimization.
o Trials are cheap. DNAv4 performs its checks using small unicast
packets. An IPv4 ARP packet on Ethernet is just 42 bytes, including
Ethernet header. This means that the cost of an unsuccessful
attempt is small, whereas the cost of a missed opportunity (having
the right address available as a candidate and choosing not to try
it for some reason) is large. The conclusion we draw from this
observation is that the best strategy is likely to be simply to try
all available candidate configurations, rather than trying to use
heuristics or hints to determine which candidates, if any, we
predict may be correct for this link. For a heuristic to usefully
eliminate a configuration from our list of candidates, it has to
(a) be fast and cheap to compute, compared to sending a 42-byte
unicast packet, and (b) have high probability of not falsely
eliminating a candidate configuration that would in fact have been
found to be the correct one. For example, eliminating a candidate
configuration just because it was obtained on a different physical
interface would not be a safe heuristic. In the case of an Ethernet
link and an 802.11 wireless link bridged together, an IP address
and default gateway obtained on the Ethernet link may continue to
be a perfectly valid and usable configuration if the host loses its
Ethernet connection and switches to 802.11 wireless.
o Time is limited. On most networks we can reasonably expect DHCP
INIT-REBOOT processing to complete in a few hundred milliseconds
at worst. This means that if DNAv4 is to provide a performance
benefit compared to DHCP INIT-REBOOT, it needs to begin within
at most a few tens of milliseconds of DHCP INIT-REBOOT processing.
Any heuristic used to eliminate candidate configurations needs to
take at most a few milliseconds to compute. In particular this
means that any heuristic based on passive observation of passing
Ethernet-level or IP-level traffic is unlikely to observe any
useful packets in the time available before DNAv4 needs to decide
whether it's going to test a candidate configuration or not.
[Bernard Aboba]
Stuart Cheshire said: "However, it turns out (I think) that this is not true. Any candidate configuration eligible for DNAv4 is also eligible for DHCP INIT-REBOOT, and INIT-REBOOT does *not* require that the client perform address conflict detection." [BA] This is accurate. Stuart Cheshire said: "Thus, all that DNAv4 is accelerating is the DHCP INIT-REBOOT REQUEST/ACK cycle." [BA] DNAv4 can still reduce delays due to conflict detection in situations where the INIT-REBOOT REQUEST/ACK cycle cannot be used. For example, if a host has moved between networks, a DHCPREQUEST will be answered with a DHCP NAK, in which case a DHCPDISCOVER will be sent. Typically implementations will not use the address on the new network until conflict detection is completed, because technically it is a *new* configuration, not reuse of an existing (valid) configuration. With DNAv4, if the new network has been previously vsitied and still has a valid lease, then the configuration will be confirmed without the additional NAK/DHCPDISCOVER cycle or the need for conflict detection. So in this case, the optimization is more substantial.
[BA] The proposed resolution is to add Section 1.1:
"1.1. Applicability DHCP is an effective and widely adopted mechanism for a host to obtain an IP address for use on a particular network link, or to re- validate a previously obtained address via DHCP's INIT-REBOOT mechanism [RFC2131]. When obtaining a new address, DHCP specifies that the client SHOULD use ARP to verify that the offered address is not already in use. The process of address conflict detection [ACD] can take as much as seven seconds. In principle this time interval could be shortened, with the obvious trade-off: the less time a host spends waiting to see if another host is already using its intended address, the greater the risk of inadvertent address conflicts. Where the client successfully re-validates a previously obtained address using the INIT-REBOOT mechanism, the DHCP specification does not require the client to perform address conflict detection, so this seven-second delay does not apply. However, the DHCP server may be slow to respond, or may be down and not responding at all, so hosts could benefit from having an alternative way to quickly determine that a previously obtained address is valid for use on this particular link. When the client moves between networks, the address re-validation attempt may be unsuccessful; a DHCPNAK may be received in response to a DHCPREQUEST, causing the client to restart the configuration process by moving to the INIT state. If an address previously obtained on the new network is still operable, DNAv4 enables the host to quickly confirm the new configuration, bypassing restart of the configuration process as well as conflict detection.
The alternative mechanism specified by this document applies when a host has a previously-allocated DHCP address, which was not returned to the DHCP server via a DHCPRELEASE message, and which still has time remaining on its lease. In this case, the host may determine whether it has re-attached to the logical link where this address is valid for use, by sending a unicast ARP Request packet to the default router previously known for that link (or in the case of a link with more than one router, by sending one or more unicast ARP Request packets to one or more of those routers). The use of unicast ARP has a number of benefits. One benefit is that unicast packets impose less burden on the network than broadcast packets, particularly on 802.11 networks where broadcast packets may be sent at rates as low as 1 Mb/sec. Another benefit is that if the host is not on the link it hoped to find itself on, a broadcast ARP Request could pollute the ARP caches of peers on that link. When using private addresses [RFC1918] another device could be legitimately using the same address, and a broadcast ARP Request could disrupt its communications, causing TCP connections to be broken, and similar problems. By using a unicast ARP packet instead, addressed to the MAC address of the router the host is expecting to find, if the host is not on the expected link, then there will be no device with that MAC address, and the ARP packet will harmlessly disappear into the void without doing any damage. These issues that define the applicability of DNAv4 lead us to a number of conclusions: o DNAv4 is a performance optimization. Its purpose is to speed up a process that may require as much as a few hundred milliseconds (DHCP INIT-REBOOT), as well as to reduce multi-second conflict detection delays when a host changes networks.
o As a performance optimization, it must not sacrifice correctness. In other words, false positives are not acceptable. DNAv4 must not conclude that a host that has returned to a previously-visited link where it has an operable IP address if this is not in fact the case. o As a performance optimization, false negatives are acceptable. It is not an absolute requirement that this optimization correctly recognize a previously-visited link in all possible cases. For example, if a router ignores unicast ARP Requests then DNAv4 will not be able to detect that it has returned to the same link in future. This is acceptable because the host still operates correctly as it did without DNAv4, just without the performance benefit. Users and network operators who desire the performance improvement offered by DNAv4 can upgrade their routers to support DNAv4. o As a performance optimization, where DNAv4 fails to provide a benefit, it should add little or no delay compared to today's DHCP processing. In practice, this implies that DHCP processing needs to proceed in parallel. Waiting for DNAv4 to fail before beginning DHCP processing can greatly increase total processing time, the opposite of the desired effect. o Trials are inexpensive. DNAv4 performs its checks using small unicast packets. An IPv4 ARP packet on Ethernet is just 42 octets, including the Ethernet header. This means that the cost of an unsuccessful attempt is small, whereas the cost of a missed opportunity (having the right address available as a candidate and choosing not to try it for some reason) is large. As a result, the best strategy is often to try all available candidate configurations, rather than trying to determine which candidates, if any, may be correct for this link, based on heuristics or hints. For a heuristic to usefully eliminate a configuration from the candidate list, it has to (a) be fast and inexpensive to compute, compared to sending a 42-octet unicast packet, and (b) have high probability of not falsely eliminating a candidate configuration that could be found to be the correct one. For example, eliminating a candidate configuration because it was obtained on a different physical interface would not be wise. In the case of an Ethernet link and an 802.11 wireless link bridged together, an IP address and default gateway on the Ethernet link may continue to represent a valid and usable configuration if the host loses its Ethernet connection and switches to 802.11 wireless. o Time is limited. If DNAv4 is to be effective in enabling low latency handoffs, it needs to complete in less than 10 ms. This implies that any heuristic used to eliminate candidate configurations needs to take at most a few milliseconds to compute. This does not leave much room for heuristics based on observation of link layer or Internet layer traffic."
Proposed Resolution: Accept
Issue 37: Technical NITs
Submitter name: Stuart Cheshire Submitter email address: cheshire@apple.com Date first submitted: October 12, 2005 Reference: http://www1.ietf.org/mail-archive/web/dhcwg/current/msg05498.html
Document: DNA-16 Comment type: T Priority: S Section: Various Rationale/Explanation of issue:
I propose the following technical edits relative to <http://www.drizzle.com/~aboba/DNA/draft-ietf-dhc-dna-ipv4-17.txt> 2 lines changed at 189 (INIT-REBOOT does not actually require the host to do Duplicate Address Detection) -- OLD TEXT -- network, without needing to re-acquire it, allowing the host to bypass Duplicate Address Detection (DAD). -- NEW TEXT -- network, without needing to re-acquire it. --------------
5 lines changed at 201 (DNAv4 does in fact slightly increase the likelihood of an address conflict) -- OLD TEXT -- DNAv4 does not increase the likelihood of an address conflict. The reachability test is only carried out for a network when the host has previously completed duplicate address detection and obtained an operable IPv4 configuration on that network. Restrictions on sending ARP Requests and Responses are described in Section 2.1.1. -- NEW TEXT -- DNAv4 does not significantly increase the likelihood of an address conflict. The reachability test is only carried out for a network when the host has previously completed address conflict detection [ACD] and obtained an operable IPv4 configuration on that network. Restrictions on sending ARP Requests and Responses are described in Section 2.1.1.
[BA] I'd prefer to reference [RFC2131] Section 2.2 instead of [ACD].
One case where DNAv4 does increase the likelihood of an address
conflict is when:
o a DHCP server hands out an address lease
o the host with that lease leaves the network
o the DHCP server is power-cycled, or crashes and is rebooted
o the DHCP server, having failed to save its lease table to
persistent storage, assigns that same address to some other host
o the first host returns, and having a still-valid lease with time
remaining, proceeds to use its assigned address, conflicting with
the new host that is now using that same address
DHCP servers are supposed to save their lease tables in persistent
storage, but almost no consumer-grade NAT gateway does so. Use of
short DHCP lease lifetimes can mitigate this risk, though use of
short DHCP lease lifetimes also limits the situations where DNAv4
has operable candidate configurations available to try.
--------------
[BA] This looks ok. 10 lines changed at 268 (remove special-case distinction for "private addresses") -- OLD TEXT -- Duplicate Address Detection on the former network does not provide assurance against an address conflict on the new network. Until a host with a private address has confirmed the operability of its IPv4 configuration, it SHOULD NOT respond to ARP Requests, and SHOULD NOT broadcast ARP Requests containing its address within the sender protocol address field (ar$spa). However, where the host has an operable routable non-private address on a network, it MAY send ARP Requests using its address within the sender protocol address field (ar$spa) prior to confirming its IPv4 configuration, and MAY respond to ARP Requests. -- NEW TEXT -- address conflict detection [ACD] on the former network does not provide assurance against an address conflict on the new network. Until a host has confirmed the operability of its IPv4 configuration by receipt of the expected ARP response from the gateway, it SHOULD NOT respond to ARP Requests, and SHOULD NOT broadcast ARP Requests containing its address within the sender protocol address field (ar$spa).
[BA] Prefer to avoid a normative reference to [ACD], but it is otherwise ok.
Proposed Resolution: Accept
Issue 38: Editorial NITs
Submitter name: Stuart Cheshire Submitter email address: cheshire@apple.com Date first submitted: October 12, 2005 Reference: http://www1.ietf.org/mail-archive/web/dhcwg/current/msg05499.html
Document: DNA-16
Comment type: E Priority: S Section: Various Rationale/Explanation of issue:
Regarding references, I think RFC792 (ICMP), RFC3118 (Authentication), and RFC3927 (IPv4LL) should be moved to Informative References (none of those are required to implement DNAv4).
I propose the following typographical edits relative to
<http://www.drizzle.com/~aboba/DNA/draft-ietf-dhc-dna-ipv4-17.txt>
1 line changed at 9
-- OLD TEXT --
Detecting Network Attachment (DNA) in IPv4
-- NEW TEXT --
Detecting Network Attachment in IPv4 (DNAv4)
--------------
1 line changed at 98
-- OLD TEXT --
[RFC2119].
-- NEW TEXT --
"Key words for use in RFCs to Indicate Requirement Levels" [RFC2119].
--------------
1 line changed at 159
-- OLD TEXT --
private addresses as specified in [RFC1918].
-- NEW TEXT --
private addresses as specified in "Address Allocation for Private
Internets" [RFC1918].
--------------
1 line changed at 164
-- OLD TEXT --
not been relinquished, and whose lease has not yet expired.
-- NEW TEXT --
not been returned to the DHCP server via a DHCP RELEASE message,
and whose lease has not yet expired.
--------------
3 lines changed at 197
-- OLD TEXT --
DHCPREQUEST from the INIT-REBOOT state, as described in [RFC2131]
Section 3.2 and 4.3.2 completes more quickly than the reachability
test(s).
-- NEW TEXT --
DHCPREQUEST from the INIT-REBOOT state, as described in Section 3.2
and 4.3.2 of the DHCP specification [RFC2131], completes more quickly
than the reachability test(s).
--------------
1 line changed at 219
-- OLD TEXT --
[b] The host does not know the default gateway(s) on
-- NEW TEXT --
[b] The host does not know the addresses of any gateway(s) on
--------------
5 lines changed at 238
-- OLD TEXT --
Note that it's not possible to get more than one reachability test
response on a given link, because the first one is the only one that
should be accepted. Once a valid reachability test response is
received, validation is complete, and additional responses (if any)
should be discarded.
-- NEW TEXT --
Once a valid reachability test response is received, validation is
complete, and any additional responses should be discarded.
--------------
2 lines changed at 247
-- OLD TEXT --
The reachability test is performed by sending an ARP Request. The
host MUST set the target protocol address (ar$tpa) to the IPv4
-- NEW TEXT --
The reachability test is performed by sending a unicast ARP Request.
The host MUST set the target protocol address (ar$tpa) to the IPv4
--------------
1 line changed at 250
-- OLD TEXT --
address field (ar$spa) to its own IPv4 address. The ARP Request MUST
-- NEW TEXT --
address field (ar$spa) to its own candidate IPv4 address.
The ARP Request MUST
--------------
2 lines changed at 263
-- OLD TEXT --
acquisition and expiration behavior described in [RFC2131], Section
4.4.5.
-- NEW TEXT --
acquisition and expiration behavior described in
Section 4.4.5 of the DHCP specification [RFC2131].
--------------
6 lines changed at 280
-- OLD TEXT --
address does not provide the same level of assurance since this may
require an ARP Request/Reply exchange. Where the host has moved
between two private networks, this could result in ARP cache
pollution.
Where a host moves from one private network to another, an ICMP Echo
-- NEW TEXT --
would not be an acceptable way of testing a candidate configuration
because sending any IP packet generally requires an ARP Request/Reply
exchange, and as explained above, ARP packets may not be broadcast
safely until *after* the operability of the candidate configuration
has been confirmed. Also, where a host moves from one private network
to another, an ICMP Echo
--------------
1 line changed at 314
-- OLD TEXT --
broadcast address as specified in [RFC2131] Section 4.4.2.
-- NEW TEXT --
broadcast address, as specified in Section 4.4.2 of the DHCP
specification [RFC2131].
--------------
2 lines changed at 318
-- OLD TEXT --
packet to the broadcast address, as described in [RFC2131] Section
4.4.1. If the host supports the Rapid Commit Option [RFC4039], it is
-- NEW TEXT --
packet to the broadcast address, as described in Section 4.4.1 of the
DHCP specification [RFC2131].
If the host supports the Rapid Commit Option [RFC4039], it is
--------------
2 lines changed at 324
-- OLD TEXT --
DHCPDISCOVER, then it retransmits as specified in [RFC2131] Section
4.1.
-- NEW TEXT --
DHCPDISCOVER, then it retransmits as specified in Section
4.1 of the DHCP specification [RFC2131].
--------------
1 line changed at 327
-- OLD TEXT --
As discussed in [RFC2131], Section 4.4.4, a host in INIT or REBOOTING
-- NEW TEXT --
As discussed in Section 4.4.4 of the DHCP specification [RFC2131], a
host in INIT or REBOOTING
--------------
2 lines changed at 361
-- OLD TEXT --
[RFC3927], and MUST NOT attempt to use DNAv4 as a shortcut to bypass
that process.
-- NEW TEXT --
"Dynamic Configuration of IPv4 Link-Local Addresses" [RFC3927], and
MUST NOT attempt to use DNAv4 as a shortcut to bypass that process.
--------------
1 line changed at 367
-- OLD TEXT --
described in [RFC2131] Section 2.3. Where a host can confirm that it
-- NEW TEXT --
described in Section 2.3 of the DHCP specification [RFC2131]. Where
a host can confirm that it
--------------
1 line changed at 370
-- OLD TEXT --
Local address is deprecated, as noted in [RFC3927] Section 1.9.
-- NEW TEXT --
Local address is deprecated, as noted in Section 1.9 of the IPv4
Link-Local specification [RFC3927].
--------------
1 line changed at 375
-- OLD TEXT --
retransmission algorithm, [RFC2131] Section 3.2 states that the
-- NEW TEXT --
retransmission algorithm, Section 3.2 of the DHCP specification
[RFC2131] states that the
--------------
Proposed Resolution: Accept
Issue 39: Multiple Packets
Submitter name: Barr Hibbs Submitter email address: rbhibbs@pacbell.net Date first submitted: October 12, 2005 Reference: http://www1.ietf.org/mail-archive/web/dhcwg/current/msg05447.html Document: DNA-16 Comment type: T Priority: S Section: Various Rationale/Explanation of issue:
I basically agree with rewording DNAv4 to permit multiple parallel efforts to configure the client. We are rapidly entering an era when network bandwidth is sufficient to all but eliminate the concern about extra traffic. Would it be appropriate to add a guideline such as: "clients on a 10 or 11 Mbit/s network SHOULD NOT attempt more than two (2) parallel reachability attempts (DHCPv4 and link local), clients on a 54 or 100 Mbit/s network SHOULD NOT attempt more than five (5), and clients operating on networks above 500 Mbits/s MAY attempt as many as they wish?" The idea being to suggest a bit of self-restraint without mandating an inflexible limit.
[Bernard Aboba]
The scenario we need to be concerned about is a power failure on a densely populated 802.11b network (e.g. an IETF meeting). Here you might have 1000+ hosts attempting to obtain configuration at roughly the same time. 80211b offers only 1-2 Mbps bandwidth for broadcast/multicast traffic and up to 11 Mbps for unicast traffic. One advantage to using unicast ARP instead of broadcast (the change introduced in -15) is the greater bandwidth availability for unicast traffic in 802.11. To prevent overload in a powerfail scenario, the major concern is limitation in the total traffic. It's not just how many parallel attempts are made, it's the spacing between attempts, the synchronization of attempts, and the number of attempts. It might be ok for an implementation to try more configurations in parallel, as long as the jitter interval was larger, so that they were spaced out over a longer period. For example, 1000 packets of 50B each is 50KB. If spread out over 100ms, this represents 4 Mbps, enough to saturate an 802.11b network with a substantial number of stations running at 5.5 Mbps rate. If spread over 200ms, this is 2 Mbps, and at 400ms, it is 1 Mbps.
[Barr Hibbs]
this is the sort of excellent discussion that might be very useful as an addendum or appendix to the RFC, providing implementors with guidelines for constructing clients, but without burdening the RFC with cast-in-concrete requirements. If the advancement of DNAv4 would NOT be held up by such an inclusion, I would suggest doing so, otherwise perhaps a draft for a BCP would be useful?
[Bernard Aboba]
Analysis shows that where DNA is handled in parallel with DHCP, traffic levels are only weakly influenced by the number of DNA probes sent, because ARP packets are small (42 bytes) and regardless of how many probes are sent, only one probe is likely to be responded to, at best. As a result, even 4 simultaneous ARP probes will only contribute 210 octets of traffic, including a single response. A more serious issue is the retransmission timeout behavior. Where multiple reachability tests are handled in parallel with DHCP, the value of retransmitting a given reachability test is marginal since only a response from a single probe is expected, and once any response is received (from either DNA or DHCP) there is no point in retransmitting. As a result, a reasonable strategy is for an implementation not to retransmit at all, or if it does, to do so only after DHCP has itself retransmitted.
The proposed resolution is to delete the following text in Section 2.1.1:
"If the initial ARP Request does not elicit a response, the host waits for REACHABILITY_TIMEOUT. The timeout value is doubled with each retransmission. It is RECOMMENDED that a host retransmit no more than twice. To provide damping in the case of spurious "Link Up" indications, it is recommended that the DNAv4 procedure be carried out no more than once a second."
Add the following text to Section 2.1:
"Where the reachability test does not return an answer, typically this is because a response is only expected from a gateway on the network to which the host has attached. As a result, there is typically little value in aggressively retransmitting reachability tests that do not elicit a response. Where DNAv4 and DHCP are tried in parallel, one strategy is to forsake reachability test retransmissions, allowing only the DHCP client to retransmit. In order to reduce competition between DNAv4 and DHCP retransmissions, a DNAv4 implementation that retransmits may utilize the retransmission strategy described in Section 4.1 of the DHCP specification [RFC2131], scheduling DNAv4 retransmissions between DHCP retransmissions. If a response is received to any reachability test or DHCP message, pending retransmissions are canceled. It is RECOMMENDED that a DNAv4 implementation retransmit no more than twice. To provide damping in the case of spurious "Link Up" indications, it is RECOMMENDED that the DNAv4 procedure be carried out no more than once a second."
Delete Section 3.
Proposed Resolution: Accept
Issue 40: DHCP Client Identifier Submitter name: David Hankins Submitter email address: david_hankins@isc.org Date first submitted: November 11, 2005 Reference: Document: DNA-17 Comment type: T Priority: S Section: 1.1 Rationale/Explanation of issue:
There was recent re-talk about the 3315 id for v4 on the wg mailing list recently, reminding me that the clause here in section 1.1:
the correct one. For example, eliminating a candidate configuration because it was obtained on a different physical interface would not be wise. In the case of an Ethernet link and an 802.11 wireless link bridged together, an IP address and default gateway on the Ethernet link may continue to represent a valid and usable configuration if the host loses its Ethernet connection and switches to 802.11 wireless.
Maybe needs to explicitly say something about client identifier? Or else remove the example. I don't know the answer, I'm asking. People get awful confused about this. I would hate to think that someone used dnav4 as an excuse to reuse a lease that was granted to a different client-identifier. Perhaps the example should be removed? I can't think of how to put the client identifier in that paragraph without sounding clunky and too technical for an intro. Maybe I'm just being paranoid.
[Stuart Cheshire] Why? Looking at the big picture, if my machine has an IP address, with life left on the lease, and can ARP the expected associated gateway, what reason is there for us to decide to make that not work? If your answer is enforcement of some security policy, then 802.1X is the way to enforce security policies. Suppose a machine has dual Ethernet ports (as many do these days) and the user connects the Ethernet cable to the other port. Should DNAv4 refuse to work in that case, just because the Ethernet packets are coming in through the wrong PHY?
[David Hankins]
> If your answer is enforcement of some security policy, then 802.1X is the > way to enforce security policies. Nono, I am the client identifier poster boy of the DHC WG, "DHCP security" is one of those things I just giggle at. > Suppose a machine has dual Ethernet ports (as many do these days) and the > user connects the Ethernet cable to the other port. Should DNAv4 refuse > to work in that case, just because the Ethernet packets are coming in > through the wrong PHY? In my opinion, "Maybe". If the client uses the same client-identifier (which may be a DUID:IAID pair within a client-identifier option) on both interfaces, DNAv4 should accept that lease from the other interface as valid and go ahead and use it. "Yes." If the client uses a different identifier on the two interfaces in question, or any other example of "differing identities", DNAv4 should refuse to adopt the lease and ask DHCP instead. "No." Because: In the second case, when the lease is renewed, a DHCP server properly implementing the protocol /will/ identify the client as distinct from the client it originally assigned the lease to, and /will/ NAK it, causing the client to change leases anyway, this time more probably at a time when the client is actually making active use of the network. The server has assigned that lease to a client identifier (or chaddr). It has not assigned it to a DUID or hardware address or "vague notion of 'client'".
Additional: The client must be prepared to use the same address on multiple interfaces in the case where the client has not moved a single connection to the physical network from one interface to another, but rather has connected the same physical network to both interfaces. It may only have enough information to learn that this has happened at a later time. In such a case, accepting the other interface's address may be disruptive to the system, if it is not prepared to handle that condition. If it is prepared to handle that condition, I would think the client would be using the same client identifier for each interface. I think all of this is may be too complicated to encode in the DNAv4 document, or at least in that section of the document. The example as it stands I think is too liberal, and might lead someone to think they should do the "No" case above. I would like to see the example cite that the candidate lease from an alternate interface MUST be so identically identified as I've described (although it need not cite 3315-id-in-v4, just identical-client-id values). I think since this may be a great number of words, the example perhaps should just be omitted, but I'm not fixed on that point. At least, I can't see a way to fit that into the example without making it very hard to read. I can take a stab at it if you'd prefer to keep the example.
[David Hankins]
I said I'd take a stab at it: "For example, eliminating a candidate configuration because it was obtained on a different physical interface would not be wise. In the case of an Ethernet link and an 802.11 wireless link bridged together, where the contents of the DHCP Client Identiifer option the client used to obtain the address on the Ethernet connection are identical to the DHCP Client Identifier option the client intends to use on the 802.11 interface, an IP address and default gateway on the Ethernet link may continue to represent a valid and usable configuration if the host loses its Ethernet connection and switches to 802.11 wireless. Such could not be said if the DHCP Client Identifier option contents differ, or if the client does not use a DHCP Client Identifier option for one of the interfaces. Note carefully that a DHCP Client Identifier option contents on one interface that match the DHCP CHADDR field contents on the other (which chooses not to supply a client identifier) does not constitute a match." And that's honestly the best I can make it. I really think no example is better.
> [2] The IPv4 configuration parameters, including
> the DHCP client identifier, assigned address and
> lease expiration time
Right on. I might have waffled about 'chaddr or client id' but I think
all the drafts the wg have made so far basically assume you provide a
client id and leave the rest to imagination, so I think you're spot-on
here.
So all we need to tie up this bundle is an explicit statement in address
selection. Most reasonable to me is to add to section 2.1 a fourth stanza:
[d] The contents of the DHCP Client Identifier option the client
used to obtain the candidate configuration is, even slightly,
different from the DHCP Client Identifier option the client
intends to present on the interface in question. In this case,
it is anticipated that a DHCP server would NAK any request made
by the client to acquire or extend the candidate configuration,
since the two interfaces are presenting differing identities.
This delivers the message without having to reference the 3315id draft.
It's also reasonably short. I'm a little worried that someone might
think different IAID's is OK so long as DUID matches, but I think this
will only hurt themselves, and the draft has done all it can to guide in
the opposite direction.
Whatever the case, the draft no longer offers suggestions that might
misguide an implementer, and explicitly mentions client identity
matching.
Once that stanza [d] or similar is in place, it feels like you've deleted
too much from the example. You can add the first sentence of the old
example back in to the overview, something like;
For example, eliminating a candidate
configuration because it was obtained on a different physical
interface would not be wise. A configuration from another
physical interface MAY be used so long as it passes the
tests outlined in Section 2.1.
If you think that's reasonable?
This gets far enough into suggesting the optimization without actually
going far enough down the path where the draft really needs to get
specific about these mythical interfaces' identities ("an Ethernet
interface and 802.11 interface that both use the same DUID and IAID
[reference] to form their DHCP Client Identifiers option contents ..
[BA] Between removing the paragraph from Section 1.1, adding the
DHCP client identifier to [2] in Section 2, and adding stanza [d] to
Section 2.1, I think we've covered the issue. Thanks!
Proposed Resolution: Accept
Issue 41: Typo Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: May 1, 2006 Reference: Document: RFC4436 Comment type: E Priority: S Section: 2.2.1 Rationale/Explanation of issue:
Section 2.2.1 states:
" If a valid ARP Reply is received, the MAC address in the sender hardware address field (ar$sha) in the ARP Reply is matched against the target hardware address field (ar$tpa) in the ARP Request, and the IPv4 address in the sender protocol address field (ar$spa) of the ARP Reply is matched against the target protocol address field (ar$tpa) in the ARP Request. "
Change "target hardware address field (ar$tpa)" to "target hardware address field (ar$tha)".
Proposed Resolution: Accept