Subject: [mobile-ip] drafts 20 and 02 have been posted

From: Jari Arkko <[email-masked]>
Date: Tue, 21 Jan 2003 00:18:44 +0200

Draft 20 for the Mobile IPv6 base and draft 02 for the
security between the home and mobile node have now been
posted. They are not yet visible in the I-D directories,
but you can access them through the following links:

   Text:
     http://www.piuha.net/~jarkko/publications/mipv6/drafts/mobilev6.txt
     http://www.piuha.net/~jarkko/publications/mipv6/drafts/mipv6haipsec.txt

   Html:
     http://www.piuha.net/~jarkko/publications/mipv6/drafts/mobilev6.html
     http://www.piuha.net/~jarkko/publications/mipv6/drafts/mipv6haipsec.html

   IPv6:
     http://[3ffe:200:8:2000::3]/~jarkko/publications/mipv6/drafts/mobilev6.html
     http://[3ffe:200:8:2000::3]/~jarkko/publications/mipv6/drafts/mipv6haipsec.html

All issues are closed as of now, I hope I didn't miss anything.
As always additional review and comments are welcome:

   http://www.piuha.net/~jarkko/publications/mipv6/MIPv6-Issues.html
   http://[3ffe:200:8:2000::3]/~jarkko/publications/mipv6/MIPv6-Issues.html

Jari

---

From: Joe Lau <[email-masked]>
Date: Mon, 20 Jan 2003 14:43:04 -0800 (PST)

Jari,

>   If both a type 0 and a type 2 routing header are present, the type 2
>   routing header should follow the other routing header.  A packet
>   containing such nested encapsulation should be created as if the
>   inner (type 2) routing header was constructed first and then treated
>   as an original packet by the outer (type 2) routing header
                                        ^^^^^^
            
You meant "outer (type 0) routing header" ?

Joe

---

From: gabriel montenegro <[email-masked]>
Date: Tue, 21 Jan 2003 00:37:27 +0100

Great work folks! The working group, the editors, and
during this last year, Jari, in particular,
deserve kudos for getting this to where it is thanks to an
ennnnnormous effort.

We'll be asking for IETF last-call on both docs as soon as they
show up on the I-D repository (a requirement for last-call).

Go take a break, Jari, you *REALLY* deserve it!

Thanks,

-gabriel

---

From: [email-masked]
Date: Tue, 21 Jan 2003 09:27:06 +0100 (MET)

Hi,

Currently, we are in Japan at the TAHI interoperability test event. We are in
charge of conformance and interoperability testing for MIPv6 draft 19. 17
implementations from 7 companies are participating to the MIPv6 ID-19
interoperability session.  
    
I see that draft 20 was available, but I didn't find time to read it.
Nevertheless, I want to report something which is always in draft 20 (perhaps it
is clarified now in another part!) and which is not clear for all the different
present companies. It concerns Neighbor Discovery proxying made by Home Agent.
Hereafter you will find an extract of draft 20 :  

10.4.1 Intercepting Packets for a Mobile Node

   While a node is serving as the home agent for mobile node it MUST
   attempt to intercept packets on the mobile node's home link that are
   addressed to the mobile node, and MUST tunnel each intercepted packet
   to the mobile node using IPv6 encapsulation [15].

   In order to do this, when a node begins serving as the home agent it
   MUST multicast onto the home link a Neighbor Advertisement message
   [12] on behalf of the mobile node.  For the home address specified in
   the Binding Update, the home agent sends a Neighbor Advertisement
   message [12] to the all-nodes multicast address on the home link, to
   advertise the home agent's own link-layer address for this IP address
   on behalf of the mobile node.

   All fields in each such Neighbor Advertisement message SHOULD be set
   in the same way they would be set by the mobile node itself if
   sending this Neighbor Advertisement [12] while at home, with the
   following exceptions:

   o  The Target Address in the Neighbor Advertisement MUST be set to
      the specific IP address for the mobile node.

   o  The Advertisement MUST include a Target Link-layer Address option
      specifying the home agent's link-layer address.

   o  The Router (R) bit in the Advertisement MUST be set to zero.

   o  The Solicited Flag (S) in the Advertisement MUST NOT be set, since
      it was not solicited by any Neighbor Solicitation.

   o  The Override Flag (O) in the Advertisement MUST be set, indicating
      that the Advertisement SHOULD override any existing Neighbor Cache
      entry at any node receiving it.

Does it mean that in the Neighbor advertisement you have to use the Mobile
Node's address as source address ? A few people here disagree and think you have
to use the Home agent address as source address. Moreover what is the scope of
the source address? Is it the Link-local address or is it the address  
present in the target field ( So it could be a global address ). It is already
an old question. As a consequence I think you have to clarifie this point. 
 
In draft 19 the use of L and S bit add problems and more complexity to this
question. But because I didn't read the new draft and because you removed the S
bit I will wait to read this in order to add more comments concerning the choice
of the source address.

-----------------
Frederic Roudaut
IRISA/INRIA
Campus de Beaulieu 
35042 RENNES CEDEX FRANCE

---

From: Francis Dupont <[email-masked]>
Date: Tue, 21 Jan 2003 16:19:07 +0100

=> this should be a standard proxy neighbor advertisement...

   Does it mean that in the Neighbor advertisement you have to use the Mobile
   Node's address as source address ?

=> no, it must be a home agent address.

   A few people here disagree and think you have
   to use the Home agent address as source address.

=> count me in them.

   Moreover what is the scope of the source address?

=> this doesn't matter. It must be a home agent address assigned to
the interface to the home link.

Thanks

[email-masked]

PS: RFC 2461 stands (to do deep changes in it is *not* in the charter of
the mobile-ip WG :-) and says in 4.4 :

      Source Address
                     An address assigned to the interface from which the
                     advertisement is sent.

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 21 Jan 2003 09:53:50 -0800

> Node's address as source address ? 

nope. HA's link local address.

Vijay

---

From: [email-masked]
Date: Wed, 22 Jan 2003 01:45:20 +0100 (MET)

Hi Francis !

In your previous mail you wrote:
> Does it mean that in the Neighbor advertisement you have to use the
> Mobile Node's address as source address ?
>

>  Source Address : An address assigned to the interface from which the
advertisement is sent.

I agree with you but consider the following extract of draft 20 (10.4.1): 

"All fields in each such Neighbor Advertisement message SHOULD be set
in the same way they would be set by the mobile node itself if
sending this Neighbor Advertisement [12] while at home, with the
following exceptions: ... "

The source address doesn't appear in the exception list.
So if the source address should be set AS IF it was the mobile node itself who
sends the Neighbor advertisement (and according to the RFC 2461 4.4) the source
address should be the MN's address. As a consequent I think that it MUST appear
in the exceptions list or otherwise a few people will still be confused.

Regards,

-----------------
Frederic Roudaut
IRISA/INRIA
Campus de Beaulieu