Subject: Re: [16ng] 66th minutes

From: Soohong Daniel Park <[email-masked]>
Date: Mon, 24 Jul 2006 18:58:26 +0900

Myungki,

Good memory. I will update the final minutes 
including your notes as well. Thanks.

NOTE: let me know if you see any missed part by
7/27. I will forward our final minutes to the IETF 
in this week due to my vacation 7/29 - 8/13.

August 11, Friday - Proceedings submission cutoff.

Daniel (Soohong Daniel Park)
Mobile Convergence Laboratory, SAMSUNG Electronics.

----- Original Message ----- 
From: "Myung-Ki Shin" <[email-masked]>
To: "Soohong Daniel Park" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, July 21, 2006 10:51 AM
Subject: Re: [16ng] 66th minutes

> Daniel,
> 
> I remembered there were some comments on 16ng's scope
> and subnet models.
> 
> Some of them might be ...
> 
> ---
> o Junghoon Jee - problem statement
> 
> Myungki) need to discuss about subnet and deployment models.
> There can be the following IP network models over 802.16 -
> 1) single/mobile device deployment model - it is WiMAX/WiBro
> 2) bridging to general ethernet model
> 3) 3g-like {RFC 3316) deployment model
> Junghoon Jee) Yes, if necessary, we will consider them, too.
> 
> o Jinhyeock Choi - IPv6 over IPv6CS
> 
> Myungki) the current doc is stable and has a good shape for WiMAX, but 
> may be not for general IPv6 CS solution.
> IETF document should have broader view rather than this.
> WiMAX is one of the current deployment examples.
> So, 16ng document should cover other deployment models, too.
> 
> ---
> 
> 
> 
> Thanks,
> Myung-Ki,
> 
> 
> Soohong Daniel Park wrote:
>> Hi folks,
>> 
>> Here is a minutes for the 16ng meeting in Montreal;
>> http://www3.ietf.org/proceedings/06jul/minutes/16ng.txt
>> 
>> Feel free to let us know your comments if any.
>> 
>> Regards,
>> 
>> Daniel (Soohong Daniel Park)
>> Mobile Convergence Laboratory, SAMSUNG Electronics.
>> _______________________________________________
>> 16ng mailing list
>> [email-masked]
>> http://eeca16.sogang.ac.kr/mailman/listinfo/16ng
>> 
> 
>
>From [email-masked] Tue Jul 25 01:00:31 2006
Date: Mon, 24 Jul 2006 07:54:08 -0700 (PDT)
From: Behcet Sarikaya <[email-masked]>
Subject: Re: [16ng] IPv6 Prefix Subnet Model Analysis DT
To: Soohong Daniel Park <[email-masked]>, [email-masked]
Reply-To: Behcet Sarikaya <[email-masked]>

--0-143555455-1153752848=:18859
Content-Type: text/plain; charset=us-ascii

Hi Daniel,
  My concern on the DT is that IPv6 subteam of WiMAX NWG is not well represented. 
  Let me repeat my request to be a member of this DT.

Regards,

Behcet

----- Original Message ----
From: Soohong Daniel Park <[email-masked]>
To: [email-masked]
Sent: Monday, July 24, 2006 12:14:55 AM
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.
_______________________________________________
16ng mailing list
[email-masked]
http://eeca16.sogang.ac.kr/mailman/listinfo/16ng

--0-143555455-1153752848=:18859
Content-Type: text/html; charset=us-ascii

<html><head><style type="text/css"><!-- DIV {margin:0px} --></style></head><body><div style="font-family:courier, monaco, monospace, sans-serif;font-size:12pt"><div style="font-family: courier,monaco,monospace,sans-serif; font-size: 12pt;">Hi Daniel,<br>&nbsp; My concern on the DT is that IPv6 subteam of WiMAX NWG is not well represented. <br>&nbsp; Let me repeat my request to be a member of this DT.<br><br>Regards,<br><br>Behcet<br><br><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;">----- Original Message ----<br>From: Soohong Daniel Park &lt;[email-masked]&gt;<br>To: [email-masked]<br>Sent: Monday, July 24, 2006 12:14:55 AM<br>Subject: [16ng] IPv6 Prefix Subnet Model Analysis DT<br><br><div>Hi folks, <br><br>We are ready to announce a new design team<br>to investigate IPv6 Prefix Subnet Model.<br><br>Here is a genda/members/milestone/etc...<br><a target="_blank"
 href="http://daniel.vsix.net/16ng/v6subnetdt.html">http://daniel.vsix.net/16ng/v6subnetdt.html</a><br><br>Thanks all members for their valuable efforts<br>in advance. We will have more details during<br>Interim on September with their deliverables.<br><br>Regards, <br><br>Daniel (Soohong Daniel Park)<br>Mobile Convergence Laboratory, SAMSUNG Electronics.<br>_______________________________________________<br>16ng mailing list<br>[email-masked]<br><a target="_blank" href="http://eeca16.sogang.ac.kr/mailman/listinfo/16ng">http://eeca16.sogang.ac.kr/mailman/listinfo/16ng</a><br></div></div><br></div></div></body></html>
--0-143555455-1153752848=:18859--
>From [email-masked] Tue Jul 25 05:15:39 2006
Date: Mon, 24 Jul 2006 21:09:14 +0200
From: Pars MUTAF <[email-masked]>
To: Dave Thaler <[email-masked]>
Subject: RE: [16ng] Re: Assumption of the Acess Router knows all
	on-linkaddresses
cc: [email-masked]

Selon Dave Thaler <[email-masked]>:

> Pars writes:
> > Is the following scenario considered important?:
> >
> > The access router learns all IPv6 addresses in the
> > subnet (from DAD).
>
> No it doesn't.  It can't, since DAD isn't seen for all addresses.
> So this scenario can't exist without changing the core IPv6
> architecture.

Hi,
OK. I ask my question differently:

How the access router could know all IP addresses in its subnet
(these hosts don't move?). And what happens if the AR has lost
the addresses?

Thank you!
pars

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

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
>From [email-masked] Tue Jul 25 05:47:33 2006
Date: Mon, 24 Jul 2006 21:41:09 +0200
From: Pars MUTAF <[email-masked]>
To: Dave Thaler <[email-masked]>
Subject: RE: [16ng] Re: Assumption of the Acess Router knows all
	on-linkaddresses
cc: [email-masked]

Thanks. I agree with you.
pars

Selon Dave Thaler <[email-masked]>:

> > -----Original Message-----
> > From: Pars MUTAF [mailto:[email-masked]]
> > Sent: Monday, July 24, 2006 12:09 PM
> > To: Dave Thaler
> > Cc: Syam Madanapalli; [email-masked]
> > Subject: RE: [16ng] Re: Assumption of the Acess Router knows all on-
> > linkaddresses
> >
> > Selon Dave Thaler <[email-masked]>:
> >
> > > Pars writes:
> > > > Is the following scenario considered important?:
> > > >
> > > > The access router learns all IPv6 addresses in the
> > > > subnet (from DAD).
> > >
> > > No it doesn't.  It can't, since DAD isn't seen for all addresses.
> > > So this scenario can't exist without changing the core IPv6
> > > architecture.
> >
> > Hi,
> > OK. I ask my question differently:
> >
> > How the access router could know all IP addresses in its subnet
> > (these hosts don't move?).
>
> It can't, unless you define a new protocol that is much more complex
> than DAD.  (I would recommend against this.)
>
> > And what happens if the AR has lost
> > the addresses?
>
> It needs to use Neighbor Discovery at the time it has a packet that it
> needs to send.
>
> -Dave
>
> > Thank you!
> > pars
> >
> >
> >
> > >
> > > -Dave
> > >
> > > > 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
> > > >
> > >
> > >
> >
> >
> >
> >
> > ----------------------------------------------------------------
> > This message was sent using IMP, the Internet Messaging Program.
>
>

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
>From [email-masked] Tue Jul 25 02:54:15 2006
To: [email-masked]
From: Margaret Wasserman <[email-masked]>
Date: Mon, 24 Jul 2006 12:47:25 -0400
Subject: [16ng] 

unsubscribe
>From [email-masked] Tue Jul 25 18:01:52 2006
Date: Tue, 25 Jul 2006 13:25:23 +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

Hi,

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

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

>
> > As I mentioned, in WiMAX one can double check the address uniqueness
> > during
> > the transport connection establishment, though this is not specified
> > currently.
>
> 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

>
> -Dave
>
> > 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] Wed Jul 26 02:36:36 2006
Date: Tue, 25 Jul 2006 09:29:51 -0700
From: Erik Nordmark <[email-masked]>
To: Syam Madanapalli <[email-masked]>
Subject: Re: [16ng] Assumption of the Acess Router knows all on-link addresses
cc: [email-masked]
cc: [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.
>    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.

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 [email-masked] Wed Jul 26 04:31:01 2006
Date: Tue, 25 Jul 2006 20:24:25 +0200
From: Pars MUTAF <[email-masked]>
To: Erik Nordmark <[email-masked]>
Subject: Re: [16ng] Assumption of the Acess Router knows all on-link addresses
cc: [email-masked]
cc: [email-masked]

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

>
> 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
> _______________________________________________
> 16ng mailing list
> [email-masked]
> http://eeca16.sogang.ac.kr/mailman/listinfo/16ng
>

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
>From [email-masked] Wed Jul 26 05:12:11 2006
Content-class: urn:content-classes:message
Subject: RE: [16ng] Assumption of the Acess Router knows all on-link addresses
Date: Tue, 25 Jul 2006 11:45:29 -0700
From: "Johnston, Dj" <[email-masked]>
To: <[email-masked]>

The generic link state notification standard in 802 is 802.21. It's just
gone through its first letter ballot.

DJ

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Pars MUTAF
Sent: Tuesday, July 25, 2006 11:24 AM
To: Erik Nordmark
Cc: [email-masked]; [email-masked]
Subject: Re: [16ng] Assumption of the Acess Router knows all on-link
addresses

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

>
> 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
> _______________________________________________
> 16ng mailing list
> [email-masked]
> http://eeca16.sogang.ac.kr/mailman/listinfo/16ng
>

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