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

From: Brett Pentland <[email-masked]>
Date: Mon, 03 Oct 2005 11:35:18 +1000

Bernard Aboba wrote:
>> He thought that it is questionable to assume that:
>>
>>    1) Every network has a router.
>>    2) you can name a network using one of its prefixes.
> 
> There are certainly adhoc networks in which there is no router.   
> However, detecting attachment to such a network is quite difficult, 
> because nodes may join and leave and therefore there is no L3 
> invariant.  That is why the DNAv4 reachability test cannot be used to 
> detect attachment to adhoc networks, but rather adhoc attachment is 
> concluded after failiure of all other approaches (reachability test, 
> DHCPv4, etc.)

OK.

> I would also agree that there are situations in which a network cannot 
> be named using one of its prefixes.  In DNAv4, a private network is not 
> suitable for identification because it is not unique.

DNAv6 might have another option.  What do you think of requiring
the router(s) on such a link to configure a ULA prefix?  The prefix
need not necessarily be advertised in a PIO in an RA, but could be
used for link identification.

Brett.

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 08 Oct 2005 10:55:26 -0700

>There are certainly adhoc networks in which there is no router.   However, 
>detecting attachment to such a network is quite difficult, because nodes 
>may join and leave and therefore there is no L3 invariant.  That is why the 
>DNAv4 reachability test cannot be used to detect attachment to adhoc 
>networks, but rather adhoc attachment is concluded after failiure of all 
>other approaches (reachability test, DHCPv4, etc.)

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.

>>I would also agree that there are situations in which a network cannot be 
>>named using one of its prefixes.  In DNAv4, a private network is not 

Along these lines, James has also proposed that confirmation of a "network 
anchor" enable the plumbing of all network configurations relating to that 
anchor.  The result of this is that networks are not named using their 
prefixes;  they are named based on the IP address/MAC address of the network 
anchor.

It seems to me that James' comments apply equally to both DNAv4 and DNAv6 
and call into question some of the fundamental assumptions that have been 
made relating to DNA.

---

From: Brett Pentland <[email-masked]>
Date: Mon, 10 Oct 2005 17:43:47 +1000

Bernard Aboba wrote:
> 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.

OK.

>>> I would also agree that there are situations in which a network 
>>> cannot be named using one of its prefixes.  In DNAv4, a private 
>>> network is not suitable for identification because it is not unique.
> 
> Along these lines, James has also proposed that confirmation of a 
> "network anchor" enable the plumbing of all network configurations 
> relating to that anchor.  The result of this is that networks are not 
> named using their prefixes;  they are named based on the IP address/MAC 
> address of the network anchor.

They might not need to be named that way either.  If there's some way
to select the network anchor then that device might be able to select
an identifier that is used for naming.  That way if the network anchor
goes away and is replaced by another, the name needn't go away with it.

> It seems to me that James' comments apply equally to both DNAv4 and 
> DNAv6 and call into question some of the fundamental assumptions that 
> have been made relating to DNA.

Decoupling DNA from both routers and prefixes has some attractions; 
stability of naming and reliance on routers, for example.  I guess we
need to look at the cost, and perhaps more importantly how a scheme
based on these network anchors would interoperate with devices/links
that don't have any support for such a scheme.

Brett.

---

From: JinHyeock Choi <[email-masked]>
Date: Tue, 11 Oct 2005 07:51:06 +0900

Dear Bernard

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

> prefixes;  they are named based on the IP address/MAC address of the network

The notion of 'network anchor' is not clear to me yet. However, if we
ssume routers are network anchors, it may cause trouble to name a
network based on IP/ MAC address of routers, in case there are
multiple routers in a link.

Right now, CPL propose to name a link/ network with 'the set of all
prefixes on the link'. Similarly, we may name a link/ network with
'the set of all routers/ network anchors on the link'.

But it's difficult to identify a router in IP layer because there may
not be a global IP address for a router (interface).

> and call into question some of the fundamental assumptions that have been

According to DNA goals, RFC 4235,

   Detecting Network Attachment (DNA) is the process by which a host
   collects the appropriate information and detects the identity of its
   currently attached link to ascertain the validity of its IP
   configuration.

Do you want to re-investigate the above?

Thanks in advance for your kind consideration.

Best Regards

JinHyeock

---

From: Greg Daley <[email-masked]>
Date: Tue, 11 Oct 2005 17:15:34 +1000

Hi Bernard,

I've got some ideas which may assist moving forward.
They're listed below.

Brett Pentland wrote:
>> 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.
> 
> 
> OK.
> 
>> named using their prefixes;  they are named based on the IP 
>> address/MAC address of the network anchor.
> 
> 

James' idea of decoupling the link identification from both routers
and prefixes does sound like an interesting idea, but I think there
are some practical constraints which affect the performance of
such a system on non adhoc networks.

I guess that my primary interest is identifying change for hosts
with ongoing sessions on the Internet.   This change can then be
used to undertake mobility operations and re-establish packet flow.
Where no router exists, the primary value upon change is in
stopping packet transmissions (as they won't succeed), and notifying
applications.

Changes to how link-change detection works in adhoc networks
with routers depends on the IPv6 subnet model being used though.

Previously we looked at unicast reachability detection for
ND hosts, using NS/NA to a device which was known to be on-link.
This allowed fast checking when the addressing and routing
configuration were still valid, but required timeout to identify
that link-change had occurred.   From what I can tell,
any scheme which uses unicast reachability probing requires
timeout before detecting if change has occurred.

Therefore, it's necessary to make use of multicast discovery
mechanisms in order to rapidly detect change.

For non adhoc hosts, Router Discovery makes a good transportation
mechanism for the link-identification information, even if the
identifier is not associated with a prefix.  Its multicast discovery
capabilities allow any identifier advertiser to immediately
identify change.

For adhoc hosts, it may be possible to use a non-prefix identifier
associated with the link.  This would presuppose adhoc hosts participate
in a routing protocol discovery which could pass such an identifier
though.

In order to supply authorization for the link-identity, this
identifier may be tied to the Internet gateway, with adhoc nodes
readvertising the link identifier sent in RAs from the router.
Authorization information could either be sent by adhoc nodes
or refer the host directly to the router.

Where no router exists, the identifier could be supplied by
a network anchor, although this may not be able to provide
explicit authorization.

If we assume that it's OK to continue to operate with IPv6
Router Discovery for non adhoc nodes, it still makes sense
to allow for introduction of non-prefix link identifiers for
these and other purposes.

To that end I suggest that DNA WG:

* Identifies if the IPv6 Subnet model for adhocs
   requires non-prefix link identifiers.

* Allow for non-prefix link identifiers to be used and tracked
   by DNAv6 hosts

* Define message formats which allow non-prefix link identifiers
   to be sent in RAs.

* Investigate requirements for configuring non-prefix link identifiers
   as a (separate) extension to the DNAv6 specification.

* Investigate requirements for passing link identification in adhoc
   networks.

The second and third points can be done initially without
clarification of the other points, so non-adhoc hosts
can still detect change using these identifiers, even if they
don't understand the special meaning of these identifiers
from a routing protocol perspective.

Does this make sense?

Greg