[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [DNA] Prefix information for link identification in DNA
FYI, the text of James' comments on DNAv4 are included below:
Date: Wed, 12 Oct 2005 08:33:24 -0400
From: James Carlson <james.d.carlson@sun.com>
To: dhcwg@ietf.org
Cc: Margaret Wasserman <margaret@thingmagic.com>, Bernard Aboba
<aboba@internaut.com>, cheshire@apple.com
Subject: proposed DNA update to remove "default gateway" references
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.