Subject: RE: [DNA] Prefix information for link identification in DNA

From: "Tero Kauppinen (JO/LMF)" <[email-masked]>
Date: Tue, 11 Oct 2005 12:27:17 +0200

> > James Carlson has recently pointed out that there really is no
intrinsic
> > reason why DNA cannot be applied to networks without a router, and
has
> > proposed modifications to DNAv4 to allow this. James has proposed
that
> DNA
> > be able to use any peer that is known to be stable as an indicator
of
> > network attachment.  This could be a router, or it could be another
> device.
> > About the only fundamental limitation is that "network anchor"
probably
> > shouldn't obtain its address dynamically.
> 
> DNA aims to ascertain the validity of its IP configuration for
> Internet connectivity, such as valid IP address or default router. So,
> when a host's IP configuration is no longer valid, it can quickly
> perform proper procedures, such as getting CoA and sending BU, to
> re-establish IP connectivity.
> 
> However, in case of a link without a router, I wonder what IP
> configuration parameter a host need to  verify for Internet
> connectivity. Also I have difficulty finding out what is the use of
> DNA in such a link.

How can it be made sure that if the node moves from one adhoc network to
another the "network anchor" identities won't happen to be the same?
After all there is no communication between these two networks. Surely
it can be made unlikely to happen by constructing the identity of
several components, but the probability would still exist. I can't stop
thinking the original simple idea of adding an identifier to the RA, but
unfortunately it had this shortcoming that it was not possible (other
than manually configuring) to make sure that adjacent networks don't use
the same identifier.

I'm also a bit worried about possible complications to the protocol if
transition from networks including a router to a network that doesn't
have a router will be supported. I would guess the transition other way
around is simpler, because when sending an RS upon detecting "link up"
the node will receive an RA.

Tero

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 11 Oct 2005 15:56:20 -0700

>another the "network anchor" identities won't happen to be the same?

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.  

>have a router will be supported. 

At least with respect to DNAv4, it doesn't appear to matter whether the
"network anchor" is a router or not.  This is, I think an important
advantage of approaches that rely on ARP/ND vs. ones that rely on RS/RA.

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 12 Oct 2005 00:19:05 -0700

> -- it cannot also be mobile.  

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

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 12 Oct 2005 08:00:09 -0700

FYI, the text of James' comments on DNAv4 are included below:

Date: Wed, 12 Oct 2005 08:33:24 -0400
From: James Carlson <[email-masked]>
To: [email-masked]
Cc: Margaret Wasserman <[email-masked]>, Bernard Aboba 
<[email-masked]>, [email-masked]
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.

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 12 Oct 2005 18:44:37 -0700

Bernard Aboba wrote:

I don't have a problem with the desire to generalize things to not 
assume routers, but the devil is in the proverbial details.

> +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
 > +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).

   Erik

---

From: Greg Daley <[email-masked]>
Date: Thu, 13 Oct 2005 13:28:59 +1000

Hi Erik,

> Bernard Aboba wrote:
[cut]
>     mobile, the host should select the default router(s) as the test

I'd like to know how you think that relates to DNA for IPv6 though.

I'm not sure this can be used to rapidly determine change like RS/RA
can (due to the solicitation going to all-routers).

Greg

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 12 Oct 2005 23:49:52 -0700

> I'd like to know how you think that relates to DNA for IPv6 though.

Good question.

For IPv6 we've been assuming that
  - we have global IPv6 prefixes (thus no confusion with 192.168.0.0/255 
being used in multiple places)
  - Router Solicitation/Advertisement being reasonably efficient (more 
efficient than sending to a DHCP server and getting a reply)

As a result of this, we can do better than IPv4 in that we can use a 
RS/RA exchange to both verify whether we are on the same link, and also 
get the new configuration information if we have moved to a different link.

So it doesn't seem that useful to follow the IPv4 model of first 
verifying that an IP+MAC address is still present on the link, since if 
we have moved we'd need to send additional packets.

*If* we want DNAv6 to handle the case when we don't have global IPv6 
prefixes, I'd suggest we do that by allowing something other than 
prefixes be used as the link identifier (as Keith Moore suggested).
This would still assume that something is sending out router 
advertisements; but a node can send a router advertisement without 
claiming to be a default router so this doesn't actually assume that 
there is a a router. One just need one or more nodes that will send out 
the RAs.

    Erik

---

From: Sathya Narayanan <[email-masked]>
Date: Thu, 13 Oct 2005 13:31:10 -0400

> prefixes be used as the link identifier (as Keith Moore suggested).

I agree.

*If* we want to allow *something* other than prefix to be used as the
link identifier, the *something* must:

1) be agreed upon by all nodes that will send RA messages.
2) be unique for each link (Weak condition: atleast for links between
which hosts could possibly move).

Since we don't know what this *something* is going to be, we cannot
specify how these two conditions are met, we need to leave that to
future specifications.

AFAICT, the only think we can achieve today is forward compatability for
hosts by defining the syntax for using *something* as link identifier.
As Hesham suggested during the last meeting, syntax can be written as a
TLV and since variable length is allowed by L, new link identifiers will
be possible. In the router advertisement processing text, we should add
a condition to check for link identifier in the RA.

The only question is *whether* we want to allow for this possibility? We
need consensus on this question to proceed further.

Sathya

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 13 Oct 2005 23:23:26 -0700

>So it doesn't seem that useful to follow the IPv4 model of first verifying 
>that an IP+MAC address is still present on the link, since if we have moved 
>we'd need to send additional packets.

DNAv4 is designed to be used in parallel with DHCP, so that multiple 
networks can be tested at the same time in addition to requesting 
configuration via DHCP.

For IPv6 this would be equivalent to using *both* ND and RS/RA in parallel.

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 14 Oct 2005 03:14:35 -0700

Bernard Aboba wrote:
>> verifying that an IP+MAC address is still present on the link, since 
>> if we have moved we'd need to send additional packets.
> 
> 

ok

> For IPv6 this would be equivalent to using *both* ND and RS/RA in parallel.

Yes, but that would still imply 3 or 4 packets instead of 2, even if the 
latency isn't any longer.

    Erik

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 14 Oct 2005 06:19:04 -0700

>latency isn't any longer.

At a minimum, it implies two packets -- but it also implies no need for 
additional protocol work.  This is something to keep in mind since DNAv4 is 
being widely implemented;  it will be tempting for those implementations may 
apply the same approach to DNAv6.

Sending more packets should not be a concern by itself; the issue is how 
many packets are sent within a given time interval.