Subject: 2nd Call for Agenda Items

From: Brian Haberman <[email-masked]>
Date: Wed, 08 Oct 2003 08:36:22 -0400

Attached is the agenda for Minneapolis as it currently stands.  Work
Group participants are encouraged to contact the chairs with other
topics they wish to have discussed at the meeting.

Regards,
Brian & Bob
IPv6 WG co-chairs

 Tuesday (11/11/03) 0900-1130
 ------------------------------
     Intro & Agenda Bashing                   5 minutes
     Milestone Review and Document Status    10 minutes
     MIB Documents                           10 minutes
     ICMP Updates                            10 minutes
     NDP/Stateless Autoconfig Updates        30 minutes
     Node Requirements                       10 minutes
     Flow Label IESG Comments                10 minutes
     Identifier/Locator Separation           15 minutes
     Interoperability Reports???              5 minutes

 Wednesday (11/12/03) 1300-1500
 ------------------------------
     Intro & Agenda Bashing                   5 minutes
     Local Addressing Requirements           20 minutes
     SL Deprecation Document                 20 minutes
     ULA Document                            15 minutes
     Address Architecture Update             15 minutes
     Scoped Address Arch Document            15 minutes

---

From: "JinHyeock Choi" <[email-masked]>
Date: Wed, 15 Oct 2003 18:07:59 +0900

Dear IPv6 group,

A while ago there was some discussion about Neighbor Discovery Update. Greg Daley 
and I collected the RA issues for Movement Detection/ Detection of Network Attachment 
in a draft: 

Router Advertisement Issues for Movement Detection/ Detection of Network Attachment 

This draft describes the problems we encountered while working on Movement Detection 
and investigates the possible solutions. We found the information in RA is not adequate for 
efficient Movement Detection due to inconsistency and incompleteness. The contents are: 

1.  Introduction
2. The RA Information Issues/ Problems
 2.1  Link local scope of Router Address
 2.2  Omission of Prefix Information 
 2.3  Lack of Solicitation Acknowledgement 
 2.4  Ambiguity of On-link information (L-bit)
3.  RA optimized for Movement Detection/ Candidate Solutions
 3.1  Complete RA
 3.2  RA with link identifier option

This document has not yet reached the ID WWW site, but is available at the URL:

http://www.ctie.monash.edu.au/ipv6/draft-jinchoi-ipv6-cRA-00.txt

We are looking forward to you feedback.

Best Regards

JinHyeock Choi and Greg Daley  

  DÅ ûúÂŠäŠx ®‹©™¨¥Šx%ŠËb¦þ¢z×è®š)â²ÚÚ¶+ÞEê®zËl†Ûi³ÿðÃ
bz×è®æj)fjåŠËbú?Š›ú

---

From: "JinHyeock Choi" <[email-masked]>
Date: Fri, 17 Oct 2003 10:54:43 +0900

Ed Remmell wrote:
> JinHyeock -
>
> Unnecessary BU is not a huge problem. So you get an extra L3 handover. Let's 

Up to some degree. We tested a link with two routers advertising two different 
prefixes. Then an MN kept sending BU whenever a new RA arrives. But this, I think, 
we'd better discuss at mip6 or DNA. 

> keep things simple... IMO this scenario you have identified is not a good 
> reason for introducing a new bit in the RA. Also, I still believe that the new 

Though it's absolute necessity can't be proved, I think it's worthwhile to investigate 
the idea of using one bit to 1) indicate completeness and 2) confirm reachability/
acknowledge solicitation.

> proposed Link Identifier RA option is an excellent solution, if you need to 
> use RAs for movement detection because you don't have reliable L2 triggers to 
> give you the same information. Some link types like WiFi will have reliable L2 
> triggers that can be used to detect a change of network (ESSID, for WiFi). In 
> that case, IMHO it is preferable to use the L2 triggers and leave the current 
> non-mobility-aware RA behavior unchanged. But, people deploying Mobile IPv6 
> will do whatever they want.

With this draft, we try to put input for ND update. So we emphasized on problems 
and gave just a brief sketch of possible solutions. I think it's DNA which will design 
MD/ DNA solution. 

Multiple prefixes on a multiple links with multiple routers makes MD very complex. 
Maybe we need some guideline for prefix assignment. IMHO, we'd better have 
better understanding on MD issues.     
 
> > > I'm not exactly sure what the purpose of non-on-link 
> > prefixes is, but 
> > > I agree, it certainly confuses things.
> > 
> > IMO, the purpose of non-on-link prefix is to check the 
> > validity of IP address. 
> > 
> > It means that an advertising router injects the route for 
> > that prefix into Internet. 
> > Assume a node has an IP address whose prefix is advertised in 
> > that link as 
> > non-on-link prefix. (For convenience, let's assume that 
> > address is globally 
> > unique.) Then Internet routing mechanism will forward  to 
> > that node any packet 
> > destined for that address.  
> 
> Yes, that's the mechanics of it. I was saying that I didn't understand why it 
> would need to be used. Actually, I just thought of a good scenario where it 

After movement, a node can use it to check whether it's current IP address 
is still valid. If the prefix of its current IP address is in an advertised RA, the 
address is topologically correct (whether L=0 or L=1) and a node can keep
using it (maybe after DAD).    

Best regards

JinHyeock

P.S I bring our discussion out so that other people may be informed and 
join it. 

> JinHyeock -
> 
> > This is the messy scenario I am worried of. 
> > 
> > 1) An MN is in Cell 1, having a CoA with Prefix A:: 
> > 2) The MN moves to Cell 2 and receives a RA with LinkID and 
> > only Prefix B::.
> > 3) MN assumes it has moved and forms a new CoA with Prefix B::.
> > 4) MN sends BU with the CoA with Prefix B::, so unnecessary 
> > BU happens.
> 
> Unnecessary BU is not a huge problem. So you get an extra L3 handover. Let's 
> keep things simple... IMO this scenario you have identified is not a good 
> reason for introducing a new bit in the RA. Also, I still believe that the new 
> proposed Link Identifier RA option is an excellent solution, if you need to 
> use RAs for movement detection because you don't have reliable L2 triggers to 
> give you the same information. Some link types like WiFi will have reliable L2 
> triggers that can be used to detect a change of network (ESSID, for WiFi). In 
> that case, IMHO it is preferable to use the L2 triggers and leave the current 
> non-mobility-aware RA behavior unchanged. But, people deploying Mobile IPv6 
> will do whatever they want.
> 
> > > I'm not exactly sure what the purpose of non-on-link 
> > prefixes is, but 
> > > I agree, it certainly confuses things.
> > 
> > IMO, the purpose of non-on-link prefix is to check the 
> > validity of IP address. 
> > 
> > It means that an advertising router injects the route for 
> > that prefix into Internet. 
> > Assume a node has an IP address whose prefix is advertised in 
> > that link as 
> > non-on-link prefix. (For convenience, let's assume that 
> > address is globally 
> > unique.) Then Internet routing mechanism will forward  to 
> > that node any packet 
> > destined for that address.  
> 
> Yes, that's the mechanics of it. I was saying that I didn't understand why it 
> would need to be used. Actually, I just thought of a good scenario where it 
> makes sense to use a non-on-link prefix: PPPv6. If the network sends a RA 
> containing prefix(es) for stateless address auto-configuration over PPPv6 to a 
> host, it could allow that same prefix to be used for stateless address auto-
> configuration on other PPPv6 links, because the network has control over the 
> assignment of the PPPv6 EUI-64 interface IDs since that is an option 
> negotiated by PPPv6.
>  
> > P.S. Can I send a copy of this to IPv6 WG? 
> Sure, no need to ask me. You can send the whole thread if you'd like ;-)
> 
> Thanks.
> - Ed
> 
> 
> ______________________________________
> This E-Mail was sent with MailMax/WEB.
> http://www.smartmax.com
>
> 
> 
> 
> > Dear Ed
> > 
> > Thanks for your comments. 
> > 
> > > I disagree. What does the MN lose by performing a L3 move in this case?
> > > Not very much. The MN needs to receive the RA first before detecting
> > > movement (L2 triggers are faster - RAs can be delayed). I have seen our
> > > MN implementation register a new care-of address with the HA in less
> > > than 1 millisecond (that was without IPsec). So, the MN drops the CoA
> > 
> > Tha's impressive. But how about DAD?  
> > 
> > > with prefix A:, does a L3 move because the link identifier changed, and
> > > then rediscovers prefix A: and auto-configures the same CoA again and
> > > reregisters it with the HA... that isn't a big problem, as far as I'm
> > > concerned. In fact, all of the extra protocol overhead involved in
> > 
> > This is the messy scenario I am worried of. 
> > 
> > 1) An MN is in Cell 1, having a CoA with Prefix A:: 
> > 2) The MN moves to Cell 2 and receives a RA with LinkID and only Prefix B::.
> > 3) MN assumes it has moved and forms a new CoA with Prefix B::.
> > 4) MN sends BU with the CoA with Prefix B::, so unnecessary BU happens.
> > 
> > > I'm not exactly sure what the purpose of non-on-link prefixes is, but I
> > > agree, it certainly confuses things. 
> > 
> > IMO, the purpose of non-on-link prefix is to check the validity of IP address. 
> > 
> > It means that an advertising router injects the route for that prefix into Internet. 
> > Assume a node has an IP address whose prefix is advertised in that link as 
> > non-on-link prefix. (For convenience, let's assume that address is globally 
> > unique.) Then Internet routing mechanism will forward  to that node any packet 
> > destined for that address.  
> > 
> > I wish the above helps. But we'd better check with the authors. Erik or Thomas.  
> > 
> > > But in this case, I would just
> > > ignore this pathological scenario.
> > 
> > This may be practical. But my point is that it is worthwhile to investigate the 
> > method of adding one additional bit to facilitate efficient MD. 
> > 
> > As before, it's illuminating to exchange opinions with you. I wish we will have 
> > a face to face discussion at Minneapolis.   
> > 
> > Best regards
> > 
> > JinHyeock
> > 
> > P.S. Can I send a copy of this to IPv6 WG? 
> > 
> >
> > 
> > 
> > > > I am afraid that there is some pathological case in which 
> > > > link identifier is 
> > > > not sufficient. Here is an example. Kindly find an attached 
> > > > file. It's difficult to draw a figure in text file. 
> > > > 
> > > > In the figure, an router has two interfaces, interface 1 and 
> > > > interface 2. To each 
> > > > interface, an AP (hence a cell) is attached. Interface 1 
> > > > advertises the prefix A:: 
> > > > and interface 2 advertises Prefix A::and B::. 
> > > > 
> > > > Cell 1 and Cell 2 can't have the same link identifier. If MN 
> > > > moves from Cell 1 to 
> > > > Cell 2, it can keep using its current CoA with Prefix A::. 
> > > > But if MN having CoA with 
> > > > Prefix B:: moves from Cell 2 to Cell 1, it can't use its CoA anymore. 
> > > > 
> > > > So MN can't check the validity of its current CoA with Link 
> > > > Identifier only. 
> > > > 
> > > 
> > > JinHyeock -
> > > 
> > > I disagree. What does the MN lose by performing a L3 move in this case?
> > > Not very much. The MN needs to receive the RA first before detecting
> > > movement (L2 triggers are faster - RAs can be delayed). I have seen our
> > > MN implementation register a new care-of address with the HA in less
> > > than 1 millisecond (that was without IPsec). So, the MN drops the CoA
> > > with prefix A:, does a L3 move because the link identifier changed, and
> > > then rediscovers prefix A: and auto-configures the same CoA again and
> > > reregisters it with the HA... that isn't a big problem, as far as I'm
> > > concerned. In fact, all of the extra protocol overhead involved in
> > > reregistering the same CoA through the new router is needed to tell the
> > > network that that CoA is now reachable through the new router, not the
> > > old router.
> > > 
> > > I'm not exactly sure what the purpose of non-on-link prefixes is, but I
> > > agree, it certainly confuses things. But in this case, I would just
> > > ignore this pathological scenario.
> > > 
> > > Thanks.
> > > - Ed
> > > 
> > > ---
> > > Outgoing mail is certified Virus Free.
> > > Checked by AVG anti-virus system (http://www.grisoft.com).
> > > Version: 6.0.522 / Virus Database: 320 - Release Date: 9/29/2003
> > >  
> > > 
> > > 
> > > 
> > > > Dear Ed
> > > > 
> > > > Thanks for prompt and helpful reply. 
> > > > 
> > > > In this draft, we try to focus on problems and present only the sketch of 
> > > > solutions. We will present more detailed solution later. 
> > > > 
> > > > > Actually, the link identifier option draft would resolve this issue, also. The 
> > > > > MN uses the RA to detect movement (assuming L2 triggers are not available). A 
> > > > > change in link identifier in the RA is enough of an indication that movement 
> > > > > has occurred.
> > > > 
> > > > I am afraid that there is some pathological case in which link identifier is 
> > > > not sufficient. Here is an example. Kindly find an attached file. It's difficult
> > > > to draw a figure in text file. 
> > > > 
> > > > In the figure, an router has two interfaces, interface 1 and interface 2. To each 
> > > > interface, an AP (hence a cell) is attached. Interface 1 advertises the prefix A:: 
> > > > and interface 2 advertises Prefix A::and B::. 
> > > > 
> > > > Cell 1 and Cell 2 can't have the same link identifier. If MN moves from Cell 1 to 
> > > > Cell 2, it can keep using its current CoA with Prefix A::. But if MN having CoA with 
> > > > Prefix B:: moves from Cell 2 to Cell 1, it can't use its CoA anymore. 
> > > > 
> > > > So MN can't check the validity of its current CoA with Link Identifier only. 
> > > > 
> > > > Multiple routers on multiple links with multiple prefixes make MD very complex. 
> > > > I think we'd better have more clear understanding. Maybe at DNA. I wish you 
> > > > participate at & contribute to DNA meeting at Minneapolis.    
> > > >  
> > > > > I looked at your draft, it is a very clear and accurate description of the 
> > > > > current issues with RAs w/ regards to using them for movement detection.
> > > > >
> > > > > Section 2.3:
> > > > > "   It may useful to assign S bit, in the case where we want nodes to be 
> > > > >    able to determine that they have received a solicited router 
> > > > >    advertisement. With S bit, a node can confirm reachability with only 
> > > > >    RS/ RA exchange."
> > > > > 
> > > > > A new bit is not needed here. If the RA is sent to a unicast destination IPv6 
> > > > > address that is local to the MN, that is sufficient. But, the router will 
> > > > 
> > > > I agree with you. But can we use it to confirm bi-directional reachability? I hope 
> > > > WG will decide so.   
> > > > 
> > > > > probably send the RA to a multicast destination address (when solicited by RS) 
> > > > > because that's what RFC-2461 recommends to do.
> > > > > 
> > > > > Section 3.1:
> > > > > "   We propose to assign a new bit (Complete bit) in RA message to 
> > > > >    indicate its completeness. When Complete bit is set, it means the RA 
> > > > >    contains all the options (including all the Prefix Information 
> > > > >    Options)."
> > > > > 
> > > > > Well, this doesn't fit too well with frequent RA beacons + MN Eager Cell 
> > > > > Switching. In that case, you want the RA to be as small as possible while 
> > > > > still supporting MN Eager Cell Switching, i.e. R-bit option is probably the 
> > > > 
> > > > I agree that it's not a good idea to send Complete RA constantly. It may take 
> > > > too much bandwidth. I think we'd better send Complete RA only when it's 
> > > > beneficial, for example when a RS is received. 
> > > > 
> > > > Thanks for your kind words. 
> > > >  
> > > > Would you put your comments in IPv6 mailing list and bring this discussion out, 
> > > > so that other people may be infomed and join it? 
> > > > 
> > > > We requested chairs for time slot at Minneapolis and it'll help us if there is a 
> > > > thread about it. We had asked at SF but denied for the lack of interests. :-(
> > > >  
> > > > Thanks for your kind words and see you at Minneapolis. 
> > > > 
> > > > Best regards
> > > > 
> > > > JinHyeock Choi
> > > > 
> > > > 
> > > > 
> > > > 
> > > > > JinHyeock & Greg -
> > > > > 
> > > > > Actually, the link identifier option draft would resolve this issue, also. The 
> > > > > MN uses the RA to detect movement (assuming L2 triggers are not available). A 
> > > > > change in link identifier in the RA is enough of an indication that movement 
> > > > > has occurred.
> > > > > 
> > > > > I looked at your draft, it is a very clear and accurate description of the 
> > > > > current issues with RAs w/ regards to using them for movement detection.
> > > > > 
> > > > > Section 2.3:
> > > > > "   It may useful to assign S bit, in the case where we want nodes to be 
> > > > >    able to determine that they have received a solicited router 
> > > > >    advertisement. With S bit, a node can confirm reachability with only 
> > > > >    RS/ RA exchange."
> > > > > 
> > > > > A new bit is not needed here. If the RA is sent to a unicast destination IPv6 
> > > > > address that is local to the MN, that is sufficient. But, the router will 
> > > > > probably send the RA to a multicast destination address (when solicited by RS) 
> > > > > because that's what RFC-2461 recommends to do.
> > > > > 
> > > > > Section 3.1:
> > > > > "   We propose to assign a new bit (Complete bit) in RA message to 
> > > > >    indicate its completeness. When Complete bit is set, it means the RA 
> > > > >    contains all the options (including all the Prefix Information 
> > > > >    Options)."
> > > > > 
> > > > > Well, this doesn't fit too well with frequent RA beacons + MN Eager Cell 
> > > > > Switching. In that case, you want the RA to be as small as possible while 
> > > > > still supporting MN Eager Cell Switching, i.e. R-bit option is probably the 
> > > > > only option needed in the RA beacon. So, I do not like this proposal, but I do 
> > > > > like "3.2 RA with Link Identifier Option". [LinkID] seems like a very good 
> > > > > solution.
> > > > > 
> > > > > Thanks.
> > > > > - Ed Remmell
> > > > > Elmic Systems, USA
> > > > > 
> > > > > 
> > > > > 
> > > > > ______________________________________
> > > > > This E-Mail was sent with MailMax/WEB.
> > > > > http://www.smartmax.com

> proposed Link Identifier RA option is an excellent solution, if you need to 
> use RAs for movement detection because you don't have reliable L2 triggers to 
> give you the same information. Some link types like WiFi will have reliable L2 
> triggers that can be used to detect a change of network (ESSID, for WiFi). In 
> that case, IMHO it is preferable to use the L2 triggers and leave the current 
> non-mobility-aware RA behavior unchanged. But, people deploying Mobile IPv6 
> will do whatever they want.
> 
> > > I'm not exactly sure what the purpose of non-on-link 
> > prefixes is, but 
> > > I agree, it certainly confuses things.
> > 
> > IMO, the purpose of non-on-link prefix is to check the 
> > validity of IP address. 
> > 
> > It means that an advertising router injects the route for 
> > that prefix into Internet. 
> > Assume a node has an IP address whose prefix is advertised in 
> > that link as 
> > non-on-link prefix. (For convenience, let's assume that 
> > address is globally 
> > unique.) Then Internet routing mechanism will forward  to 
> > that node any packet 
> > destined for that address.  
> 
> Yes, that's the mechanics of it. I was saying that I didn't understand why it 
> would need to be used. Actually, I just thought of a good scenario where it 
> makes sense to use a non-on-link prefix: PPPv6. If the network sends a RA 
> containing prefix(es) for stateless address auto-configuration over PPPv6 to a 
> host, it could allow that same prefix to be used for stateless address auto-
> configuration on other PPPv6 links, because the network has control over the 
> assignment of the PPPv6 EUI-64 interface IDs since that is an option 
> negotiated by PPPv6.
>  
> > P.S. Can I send a copy of this to IPv6 WG? 
> Sure, no need to ask me. You can send the whole thread if you'd like ;-)
> 
> Thanks.
> - Ed
> 
> 
> ______________________________________
> This E-Mail was sent with MailMax/WEB.
> http://www.smartmax.com
>
> 
> 
> 
> > Dear Ed
> > 
> > Thanks for your comments. 
> > 
> > > I disagree. What does the MN lose by performing a L3 move in this case?
> > > Not very much. The MN needs to receive the RA first before detecting
> > > movement (L2 triggers are faster - RAs can be delayed). I have seen our
> > > MN implementation register a new care-of address with the HA in less
> > > than 1 millisecond (that was without IPsec). So, the MN drops the CoA
> > 
> > Tha's impressive. But how about DAD?  
> > 
> > > with prefix A:, does a L3 move because the link identifier changed, and
> > > then rediscovers prefix A: and auto-configures the same CoA again and
> > > reregisters it with the HA... that isn't a big problem, as far as I'm
> > > concerned. In fact, all of the extra protocol overhead involved in
> > 
> > This is the messy scenario I am worried of. 
> > 
> > 1) An MN is in Cell 1, having a CoA with Prefix A:: 
> > 2) The MN moves to Cell 2 and receives a RA with LinkID and only Prefix B::.
> > 3) MN assumes it has moved and forms a new CoA with Prefix B::.
> > 4) MN sends BU with the CoA with Prefix B::, so unnecessary BU happens.
> > 
> > > I'm not exactly sure what the purpose of non-on-link prefixes is, but I
> > > agree, it certainly confuses things. 
> > 
> > IMO, the purpose of non-on-link prefix is to check the validity of IP address. 
> > 
> > It means that an advertising router injects the route for that prefix into Internet. 
> > Assume a node has an IP address whose prefix is advertised in that link as 
> > non-on-link prefix. (For convenience, let's assume that address is globally 
> > unique.) Then Internet routing mechanism will forward  to that node any packet 
> > destined for that address.  
> > 
> > I wish the above helps. But we'd better check with the authors. Erik or Thomas.  
> > 
> > > But in this case, I would just
> > > ignore this pathological scenario.
> > 
> > This may be practical. But my point is that it is worthwhile to investigate the 
> > method of adding one additional bit to facilitate efficient MD. 
> > 
> > As before, it's illuminating to exchange opinions with you. I wish we will have 
> > a face to face discussion at Minneapolis.   
> > 
> > Best regards
> > 
> > JinHyeock
> > 
> > P.S. Can I send a copy of this to IPv6 WG? 
> > 
> >
> > 
> > 
> > > > I am afraid that there is some pathological case in which 
> > > > link identifier is 
> > > > not sufficient. Here is an example. Kindly find an attached 
> > > > file. It's difficult to draw a figure in text file. 
> > > > 
> > > > In the figure, an router has two interfaces, interface 1 and 
> > > > interface 2. To each 
> > > > interface, an AP (hence a cell) is attached. Interface 1 
> > > > advertises the prefix A:: 
> > > > and interface 2 advertises Prefix A::and B::. 
> > > > 
> > > > Cell 1 and Cell 2 can't have the same link identifier. If MN 
> > > > moves from Cell 1 to 
> > > > Cell 2, it can keep using its current CoA with Prefix A::. 
> > > > But if MN having CoA with 
> > > > Prefix B:: moves from Cell 2 to Cell 1, it can't use its CoA anymore. 
> > > > 
> > > > So MN can't check the validity of its current CoA with Link 
> > > > Identifier only. 
> > > > 
> > > 
> > > JinHyeock -
> > > 
> > > I disagree. What does the MN lose by performing a L3 move in this case?
> > > Not very much. The MN needs to receive the RA first before detecting
> > > movement (L2 triggers are faster - RAs can be delayed). I have seen our
> > > MN implementation register a new care-of address with the HA in less
> > > than 1 millisecond (that was without IPsec). So, the MN drops the CoA
> > > with prefix A:, does a L3 move because the link identifier changed, and
> > > then rediscovers prefix A: and auto-configures the same CoA again and
> > > reregisters it with the HA... that isn't a big problem, as far as I'm
> > > concerned. In fact, all of the extra protocol overhead involved in
> > > reregistering the same CoA through the new router is needed to tell the
> > > network that that CoA is now reachable through the new router, not the
> > > old router.
> > > 
> > > I'm not exactly sure what the purpose of non-on-link prefixes is, but I
> > > agree, it certainly confuses things. But in this case, I would just
> > > ignore this pathological scenario.
> > > 
> > > Thanks.
> > > - Ed
> > > 
> > > ---
> > > Outgoing mail is certified Virus Free.
> > > Checked by AVG anti-virus system (http://www.grisoft.com).
> > > Version: 6.0.522 / Virus Database: 320 - Release Date: 9/29/2003
> > >  
> > > 
> > > 
> > > 
> > > > Dear Ed
> > > > 
> > > > Thanks for prompt and helpful reply. 
> > > > 
> > > > In this draft, we try to focus on problems and present only the sketch of 
> > > > solutions. We will present more detailed solution later. 
> > > > 
> > > > > Actually, the link identifier option draft would resolve this issue, also. The 
> > > > > MN uses the RA to detect movement (assuming L2 triggers are not available). A 
> > > > > change in link identifier in the RA is enough of an indication that movement 
> > > > > has occurred.
> > > > 
> > > > I am afraid that there is some pathological case in which link identifier is 
> > > > not sufficient. Here is an example. Kindly find an attached file. It's difficult
> > > > to draw a figure in text file. 
> > > > 
> > > > In the figure, an router has two interfaces, interface 1 and interface 2. To each 
> > > > interface, an AP (hence a cell) is attached. Interface 1 advertises the prefix A:: 
> > > > and interface 2 advertises Prefix A::and B::. 
> > > > 
> > > > Cell 1 and Cell 2 can't have the same link identifier. If MN moves from Cell 1 to 
> > > > Cell 2, it can keep using its current CoA with Prefix A::. But if MN having CoA with 
> > > > Prefix B:: moves from Cell 2 to Cell 1, it can't use its CoA anymore. 
> > > > 
> > > > So MN can't check the validity of its current CoA with Link Identifier only. 
> > > > 
> > > > Multiple routers on multiple links with multiple prefixes make MD very complex. 
> > > > I think we'd better have more clear understanding. Maybe at DNA. I wish you 
> > > > participate at & contribute to DNA meeting at Minneapolis.    
> > > >  
> > > > > I looked at your draft, it is a very clear and accurate description of the 
> > > > > current issues with RAs w/ regards to using them for movement detection.
> > > > >
> > > > > Section 2.3:
> > > > > "   It may useful to assign S bit, in the case where we want nodes to be 
> > > > >    able to determine that they have received a solicited router 
> > > > >    advertisement. With S bit, a node can confirm reachability with only 
> > > > >    RS/ RA exchange."
> > > > > 
> > > > > A new bit is not needed here. If the RA is sent to a unicast destination IPv6 
> > > > > address that is local to the MN, that is sufficient. But, the router will 
> > > > 
> > > > I agree with you. But can we use it to confirm bi-directional reachability? I hope 
> > > > WG will decide so.   
> > > > 
> > > > > probably send the RA to a multicast destination address (when solicited by RS) 
> > > > > because that's what RFC-2461 recommends to do.
> > > > > 
> > > > > Section 3.1:
> > > > > "   We propose to assign a new bit (Complete bit) in RA message to 
> > > > >    indicate its completeness. When Complete bit is set, it means the RA 
> > > > >    contains all the options (including all the Prefix Information 
> > > > >    Options)."
> > > > > 
> > > > > Well, this doesn't fit too well with frequent RA beacons + MN Eager Cell 
> > > > > Switching. In that case, you want the RA to be as small as possible while 
> > > > > still supporting MN Eager Cell Switching, i.e. R-bit option is probably the 
> > > > 
> > > > I agree that it's not a good idea to send Complete RA constantly. It may take 
> > > > too much bandwidth. I think we'd better send Complete RA only when it's 
> > > > beneficial, for example when a RS is received. 
> > > > 
> > > > Thanks for your kind words. 
> > > >  
> > > > Would you put your comments in IPv6 mailing list and bring this discussion out, 
> > > > so that other people may be infomed and join it? 
> > > > 
> > > > We requested chairs for time slot at Minneapolis and it'll help us if there is a 
> > > > thread about it. We had asked at SF but denied for the lack of interests. :-(
> > > >  
> > > > Thanks for your kind words and see you at Minneapolis. 
> > > > 
> > > > Best regards
> > > > 
> > > > JinHyeock Choi
> > > > 
> > > > 
> > > > 
> > > > 
> > > > > JinHyeock & Greg -
> > > > > 
> > > > > Actually, the link identifier option draft would resolve this issue, also. The 
> > > > > MN uses the RA to detect movement (assuming L2 triggers are not available). A 
> > > > > change in link identifier in the RA is enough of an indication that movement 
> > > > > has occurred.
> > > > > 
> > > > > I looked at your draft, it is a very clear and accurate description of the 
> > > > > current issues with RAs w/ regards to using them for movement detection.
> > > > > 
> > > > > Section 2.3:
> > > > > "   It may useful to assign S bit, in the case where we want nodes to be 
> > > > >    able to determine that they have received a solicited router 
> > > > >    advertisement. With S bit, a node can confirm reachability with only 
> > > > >    RS/ RA exchange."
> > > > > 
> > > > > A new bit is not needed here. If the RA is sent to a unicast destination IPv6 
> > > > > address that is local to the MN, that is sufficient. But, the router will 
> > > > > probably send the RA to a multicast destination address (when solicited by RS) 
> > > > > because that's what RFC-2461 recommends to do.
> > > > > 
> > > > > Section 3.1:
> > > > > "   We propose to assign a new bit (Complete bit) in RA message to 
> > > > >    indicate its completeness. When Complete bit is set, it means the RA 
> > > > >    contains all the options (including all the Prefix Information 
> > > > >    Options)."
> > > > > 
> > > > > Well, this doesn't fit too well with frequent RA beacons + MN Eager Cell 
> > > > > Switching. In that case, you want the RA to be as small as possible while 
> > > > > still supporting MN Eager Cell Switching, i.e. R-bit option is probably the 
> > > > > only option needed in the RA beacon. So, I do not like this proposal, but I do 
> > > > > like "3.2 RA with Link Identifier Option". [LinkID] seems like a very good 
> > > > > solution.
> > > > > 
> > > > > Thanks.
> > > > > - Ed Remmell
> > > > > Elmic Systems, USA
> > > > > 
> > > > > 
> > > > > 
> > > > > ______________________________________
> > > > > This E-Mail was sent with MailMax/WEB.
> > > > > http://www.smartmaxLR¿¬(®H§‚
èº™šŠX§‚X¬¶*oê'~ŠàÙ¢ž+-«b½ä^ªç¬¶Èm¶›?ÿ0Ö'~Šàþf¢–f§þX¬¶)ß£ø©¿