Subject: [16ng] Assumption of the Acess Router knows all on-link addresses

From: "Syam Madanapalli" <[email-masked]>
Date: Fri, 21 Jul 2006 08:45:03 +0530

Hi,

>From the 16ng minutes:

    Dave Thaler: On IP*CS, the assumption that the router knows all on-link
    addresses based on DAD does not hold in the IPv6 architecture/protocol.
    There are at least 4 reasons, probably more, why this is a faulty
     assumption.

The current WiMAX solution is based on this assumption, so will you please
provide reasons why this assumption is faulty?

Learning addresses in use using DAD is one mechanism. The AR can also
learn from MLD and may be from 802.16 MAC connection establishment etc.
And in case the AR does not know about the address, an MS may not be able to
communicate using that address.

Thanks,
Syam
_______________________________________________
16ng mailing list
[email-masked]
http://eeca16.sogang.ac.kr/mailman/listinfo/16ng

---

From: "Syam Madanapalli" <[email-masked]>
Date: Mon, 24 Jul 2006 08:50:32 +0530

Hi,

On 7/22/06, Dave Thaler <[email-masked]> wrote:
> There are now at least 5 (probably more reasons).
> The main point is that the IPv6 protocol was not designed with any such
> assumption, but instead was designed with the opposite assumption...
> that no one other than the address owner ever knows the complete list.

At least ISP should know the address so that he can allow
the communication. I think, we can assume this.

>
> The 5 reasons known so far are:
> 1) Packet loss (DAD isn't sent reliably)
> 2) Anycast addresses.  Per RFC 2462, DAD MUST NOT be done on anycast
> addresses, but they are then used just like unicast addresses.
> 3) DupAddrDetectTransmits can be configured to be 0, in which case
> you won't see any DAD.

I think the above 3 apply for the RFC 2642 as well.
In WiMAX, one can double check during the MAC transport connection
for the address uniqueness.

> 4) RFC 2462 contains a clause in 5.4 whereby DAD may be skipped
> for global addresses if you already did DAD on the link-local with
> the same interface identifier.

This has been deprecated in 2462bis:

      "this kind of
      "optimization" is NOT RECOMMENDED, and new implementations MUST
      NOT do that optimization."

> 5) The link may be partitioned for various reasons.  For example,
> there can be devices in between the router and the host which
> act like a hub in that the host thinks the link is up and does DAD,
> but where the hub is disconnected from the router.

Again I am not sure how this is handled with RFC 2462.

>
> The above list is almost certainly not exhaustive, and more reasons can
> be added at any time, given the IPv6 architecture.
>
> Bottom line is that you cannot base anything on the assumption that
> anyone else is authoritative besides the host.  You can use a cache for
> optimization, but never as an authoritative source.

Sure. Currently Address Cache is almost being used as an authoritative source.
I think the missing of an address in this list, may be because of one
of the above
causes which I this is problem for RFC 2462 as well.

As I mentioned, in WiMAX one can double check the address uniqueness during
the transport connection establishment, though this is not specified currently.

Thanks,
Syam

>
> -Dave
>
> -----Original Message-----
> From: Syam Madanapalli [mailto:[email-masked]]
> Sent: Thursday, July 20, 2006 8:15 PM
> To: Dave Thaler
> Cc: [email-masked]; Soohong Daniel Park
> Subject: Assumption of the Acess Router knows all on-link addresses
>
> Hi,
>
> From the 16ng minutes:
>

---

From: Pars Mutaf <[email-masked]>
Date: Mon, 24 Jul 2006 11:13:59 +0200

Hello, 

Is the following scenario considered important?:

The access router learns all IPv6 addresses in the
subnet (from DAD). But, the access router crashes,
and you replace it with another one
(or it reboots with loss of state because of power 
cut etc). For example 10000 subscribers are currently 
in the subnet. They all become disconnected?

I'm asking this question because, normally IPv6
could automatically recover from such a bad 
situation without problem (because it has a 'reactive' 
neighbor discovery mechanism).

May be the Wimax hosts should perform DAD frequently
to make sure that the AR did not forget their address? 
How frequently?

Thanks
pars

---

From: "Syam Madanapalli" <[email-masked]>
Date: Tue, 25 Jul 2006 13:25:23 +0530

Hi,

> It doesn't prevent duplicates in this case.  However the address space
> is so large the issue is largely ignored as far as duplicates are
> concerned.  There hasn't been any real need to solve the problem of
> duplicate detection given the high complexity and low benefit that would
> result.  The important thing is just that the router can never rely on
> DAD for learning addresses.

The same characteristics of IPv6 address space is available for WiMAX as well.
So even if the router relies on address cache even if it is incomplete, it is ok
for the reason you mentioned.

> Nope, there is no such problem in IPv6.  We need to make sure 16ng
> doesn't try to change the IPv6 architecture by trying to introduce any
> faulty assumption that the router can build an authoritative cache from
> DAD.
>
> IPv6 does not provide a 100% guarantee that duplicates are detected.
> IPv6 does however, ensure that if you do have a unique address, that the
> router will be able to find you given that address.
>
> The "authoritative cache" proposal incorrectly assumes that it does
> provide a 100% guarantee, and breaks the ability of a router to find you
> given an address which it does not have in the cache.

Router does not try to find any host based on address cache for packet
forwarding. Router looks for existence of MAC transport connection for
packet forwarding. It does not even required to do the ND. The address
cache is only used for relaying the DAD probe.

> The main problem isn't uniqueness.  It's handling of a data packet
> destined to an address for which the router has seen no DAD.  The IPv6
> architecture supports delivery of such packets since this can be a
> normal occurrence.  16ng should not break this.

Please see the above text. Packet forwarding is based on the existence
of MAC transport connection but not the existence of a address in the
address cache.

And couple of comments:

The address cache will be incomplete because of
the way RFC 2461/2 are defined. The causes you
mentioned for incomplete address cache are problems
for Ethernet case as well.

For the reasons you mentioned, the address cache
may be in complete but I could not understand how
this is problem for the WiMAX not for the Ethernet
case. If the duplicates exist because of address
cache for the reasons you mentioned is incomplete,
so is in Ethernet case.

Having said that, this kind of shared model may
have problems in supporting multiple routers on the
same link as well as link local multicast; though
currently WiMAX does not require both of these.

And again, In WiMAX Networks the packet forwarding is
based on the existence of MAC transport connection.

May be we should wait for the design team to come up
with a model that suits best for IPv6 architecture and
802.16 characteristics.

Thanks,
Syam

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 25 Jul 2006 09:29:51 -0700

> communicate using that address.

The DAD and MLD approaches to learning might not be completely reliable, 
especially if we are concerned about the AR crashing and rebooting.

But learning the IPv6 address(es) of the MS from 802.16 signaling (such 
as the connection establishment) seems to be a reliable option. If the 
AR crashes one would assume that all the MAC connections would be 
dropped, which means the hosts would have to re-establish the MAC 
connections, hence the AR would find out about the IPv6 addresses again.

But we need to make sure that the above works when the host is using 
multiple IPv6 addresses on the 802.16 network interface. Would the host 
have a separate MAC connection for each IPv6 address? Or is there a way 
for the host to add an IPv6 address to an existing MAC connection?
(It seems like those capabilties would be required even without the 
learning on the AR, since the AR would need to know which IPv6 address 
should be sent to which CID AFAICT.)

    Erik

---

From: Pars MUTAF <[email-masked]>
Date: Tue, 25 Jul 2006 20:24:25 +0200

Hi,

> especially if we are concerned about the AR crashing and rebooting.

We should be concerned IMO. It will happen sooner or later. And the
consequences would be really serious if everybody becomes unreachable.
In addition, the probability of crash (or temporary power cut etc.)
is not avoidable in some countries. These contries will prefer
IP because it is the cheapest, easiest solution (I guess).

Another motivation is disaster (disaster->powercut->reboot).

IP can easily recover from loss of state (normally). It was designed for
this (no?).

> connections, hence the AR would find out about the IPv6 addresses again.

I think there should be a notification that the MAC connection is not available
(lost) and the host must re-establish it. Otherwise idle hosts that expect
incoming sessions (using e.g. MIPv6) would become unreachable without knowing
it.

Does 802.16 have such notification signaling?

If not, there are two choices IMHO:

1. Using standard neighbor discovery. Upon incoming session, the access router
would broadcast a neighbor solicitation over the subnet. The destination host
would re-establish its MAC connection and receive the packet. Is this possible
over 802.16? If we can broadcast router advertisements, why we can't broadcast
a neighbor solication?

2. If the AR needs all MAC connections and all IP addresses in the subnet
at the same time (for some reason that I don't understand), then
it can broadcast an "alert: MAC connections are lost!" message. Upon receipt of
this message, every host would re-establish its MAC connection proactively.

The first one is of course better (more resource efficient in terms of
bandwidth, energy and access router CPU). It is on demand.

Thanks,
pars

>     Erik

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
_______________________________________________
16ng mailing list
[email-masked]
http://eeca16.sogang.ac.kr/mailman/listinfo/16ng

---

From: "Syam Madanapalli" <[email-masked]>
Date: Wed, 26 Jul 2006 13:23:33 +0530

Hello Erik,

> for the host to add an IPv6 address to an existing MAC connection?

It is possible to create multiple connections with single IP address for
different QoS needs. It is also possible to create a sing connection for
multiple IP addresses as long all the packet flows fit into the QoS
supported by that connection. MS can specify all the IP addresses
that should be mapped to particular connection while creating a connection.
It can also make changes to the existing connection during which MS
should be able to specify more addresses to map to the existing connection.
It is also possible to delete some of the IP addresses associated with a
particular connection.

> should be sent to which CID AFAICT.)

I think, according to IEEE 802.16, the IP addresses are optional;  this may be
problem for router to forward the packets to an MS if it does not specify its
IP address. May be we should recommend to always include its IP address
when creating a connection.

Regds,
Syam

---

From: "Syam Madanapalli" <[email-masked]>
Date: Wed, 26 Jul 2006 13:41:05 +0530

[cut]
> > So even if the router relies on address cache even if it is incomplete, it
> > is ok for the reason you mentioned.
>
> It is ok as far as _duplicate detection_ is concerned (if you don't care
> about fast mobility that is), but this is separate from neighbor
> discovery.

Yes, nonetheless we should care about mobility as 802.16e supports
full mobility while developing a full solution.

[cut]
> Ok, I don't know what "MAC transport connection" means, or what the
> relationship between that and an IP address is.  If a host has 20 IP
> addresses, is there one MAC transport connection, or 20?  What causes
> a MAC transport connection to be established?

It should be possible to establish 20 connection for a single IP address,
may be for having different QoS requirements; packet mapping to CID may
be decided by the use of other header fields like Flow Label, Traffic Class etc.
It should also possible to map 20 IP addresses to a single MAC connection.
In any case the access router should know about the IP address and other
classifiers for mapping a packet to a particular connection.

[cut]
> I'm not sure what problem you're referring to on Ethernet.
> If you're only referring to duplicate detection, then yes.

Yes I am referring to DAD only.

Thanks,
Syam

---

From: Pars Mutaf <[email-masked]>
Date: Wed, 26 Jul 2006 13:55:08 +0200

> bandwidth, energy and access router CPU). It is on demand.

A quick precision:
If we don't use an on-demand MACconnection/IPaddress recovery 
mechanism (i.e. Neighbor Discovery), the hosts will "panic".

Upon access router crash and reboot, all hosts will detect MAC
connection loss (unclear how.. using 802.21??) and try to 
re-establish it proactively at the same time. 

The AR will have to handle thousands MAC connection establishment 
requests at the same time. This scenario may reduce 
the scalability (i.e. subnet size) of the solution.

Regards,
pars