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

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:
>
>    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
>
>From [email-masked] Mon Jul 24 15:21:31 2006
Date: Mon, 24 Jul 2006 14:14:55 +0900
From: Soohong Daniel Park <[email-masked]>
To: [email-masked]
Subject: [16ng] IPv6 Prefix Subnet Model Analysis DT

Hi folks, 

We are ready to announce a new design team
to investigate IPv6 Prefix Subnet Model.

Here is a genda/members/milestone/etc...
http://daniel.vsix.net/16ng/v6subnetdt.html

Thanks all members for their valuable efforts
in advance. We will have more details during
Interim on September with their deliverables.

Regards, 

Daniel (Soohong Daniel Park)
Mobile Convergence Laboratory, SAMSUNG Electronics.
>From [email-masked] Mon Jul 24 19:23:25 2006
Subject: Re: [16ng] Re: Assumption of the Acess Router knows all on-link
	addresses
From: Pars Mutaf <[email-masked]>
To: Syam Madanapalli <[email-masked]>
Organization: INT Evry
Date: Mon, 24 Jul 2006 11:13:59 +0200
cc: [email-masked]
cc: Dave Thaler <[email-masked]>
Reply-To: [email-masked]

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

On Mon, 2006-07-24 at 08:50 +0530, Syam Madanapalli wrote:
> 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:
> >
> >    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: Wed, 26 Jul 2006 13:23:33 +0530

Hello Erik,

On 7/25/06, Erik Nordmark <[email-masked]> wrote:
> Syam Madanapalli wrote:
> > 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.
> > The current WiMAX solution is based on this assumption, so will you please
> 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 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.

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

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
>
>    Erik
>
>From [email-masked] Wed Jul 26 18:17:46 2006
Date: Wed, 26 Jul 2006 13:41:05 +0530
From: "Syam Madanapalli" <[email-masked]>
To: "Dave Thaler" <[email-masked]>
cc: [email-masked]
Subject: [16ng] Re: Assumption of the Acess Router knows all on-link addresses

[cut]
> > 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.
>
> 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]
> > > 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.
>
> 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]
> > > 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.
>
> 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

>
> > 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 [email-masked] Wed Jul 26 22:02:20 2006
Subject: Re: [16ng] Assumption of the Acess Router knows all on-link
	addresses
From: Pars Mutaf <[email-masked]>
To: Erik Nordmark <[email-masked]>
Organization: INT Evry
Date: Wed, 26 Jul 2006 13:55:08 +0200
cc: [email-masked]
cc: [email-masked]
Reply-To: [email-masked]

On Tue, 2006-07-25 at 20:24 +0200, Pars MUTAF wrote:
> Hi,
> 
> Selon Erik Nordmark <[email-masked]>:
> 
> > Syam Madanapalli wrote:
> > > 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.
> > > The current WiMAX solution is based on this assumption, so will you please
> > The DAD and MLD approaches to learning might not be completely reliable,
> > 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?).
> 
> >
> > 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.
> 
> 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.

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

> >
> > 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.)
> 
> 
> Thanks,
> pars
> 
> 
> >
> >     Erik
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.

---

From: "Junghoon Jee" <[email-masked]>
Date: Thu, 3 Aug 2006 10:48:06 +0900

Hello Syam,
Please find very short questio below,

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Syam 
> Madanapalli
> Sent: Friday, July 21, 2006 12:15 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [16ng] Assumption of the Acess Router knows all 
> on-link addresses
> 
> 
> Hi,
> 
> >From the 16ng minutes:
> 
> 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.

Could you clarify how AR can learn all the on-link addresses of SSs
from the 802.16 MAC connections?
It is more general to take consideration about the fact that the AR is
separated from the BS where the 802.16 classification occurs.

Best Regards,
-Junghoon 

> And in case the AR does not know about the address, an MS may 
> not be able to communicate using that address.
> 
> 
> Thanks,
> Syam

---

From: "Syam Madanapalli" <[email-masked]>
Date: Thu, 3 Aug 2006 08:28:33 +0530

Hi Junghoon,

> separated from the BS where the 802.16 classification occurs.

In WiMAX Architecture he connection is extended to ASN GW by
having a R6 tunnel between BS and ASN GW.

Thanks,
Syam

>From [email-masked] Thu Aug  3 14:40:54 2006
From: "Junghoon Jee" <[email-masked]>
To: "'Syam Madanapalli'" <[email-masked]>
Subject: RE: [16ng] Assumption of the Acess Router knows all on-link addresses
Date: Thu, 3 Aug 2006 13:32:30 +0900
cc: [email-masked]
cc: [email-masked]

> > > 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.
> >
> In WiMAX Architecture he connection is extended to ASN GW by 
> having a R6 tunnel between BS and ASN GW.

Yes, I already know about the WiMAX architecture model where the GRE
tunnel is used between BS and ASN GW.
So, how the GRE tunnels are utilized for an ASN GW to learn the all
the on-link addresses of SSs?
 
-Junghoon