[dhcwg] proposed DNA update to remove "default gateway" references

[James Carlson <[e-mail]>]

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. 

_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg