Subject: RE: [mobile-ip] Mobile IPv6 draft revision

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Tue, 21 Aug 2001 03:55:53 +0200

> > > - Reorganizing the Binding Update format so that:
> > >   = authentication data is able to be included as a suboption
> > >
> >         => Is this needed ? Based on the point below we can eliminate
> >         this completely. There was a concern on how this would
> >         work with IKE. Will that be addressed ?
> 
> I don't know what to put in the draft about IKE.  I understand we're
> not supposed to be messing with IKE, and I am pretty sure it's too
> much work to mandate for all correspondent nodes.
> 
	=> I wasn't suggesting mandating it, but to allow it as an option. 
	I didn't raise the IKE DOI issue and I don't know enough about IKE
	to help here but I thought it was worth reminding you about this 
	since you're updating the draft. 

> > >   = Specify that the Binding Update needs a new header number
> > >
> >         => Should this one be kept for MIPv6 options as well ?
> >         Like the home adderss option for example.
> 
> The home address option does not have to be authenticated.
> 
	=> I undersand but it would make sense to avoid having another 
	header if we alow the authentication data in the BU option. 
	This is the hypothetical scenario: 
	The BU carries its own authentication data. In this case the Home 
	address option need not be in the DST-1 header. So it can be placed
	in the same "new" ext header. Provided that there was nothing else
	in a DST header we've saved the overhead of one ext header.

> I reckon that the Binding Acknowledgement would need to have
> a new header number also -- or else if there is a need to conserve
> those numbers it could have the same header number as the
> Binding Update.
> 
	=> Definitely use the same ext header. There is no reason for 
	a separate one as far as I can see.

	Hesham

---

From: Peter Grimstrup <[email-masked]>
Date: Tue, 21 Aug 2001 08:59:47 +0200

A few comments mainly from an implementation point of view:

In draft-13, the MIPv6 protocol data was put into up to *2* Destination Option
Headers. These headers had to be placed correctly in between the other
ext-headers (before/after AH). Another (not yet defined) dest-opt header could be
in the packet. That wasn't very clean.

I should like to see new header extension types defined in the same breathing as
the requirement on ordering of all the extension headers.
That said, if possible, I favour putting *all* MIPv6 data (incl. Home Address
Option) into *one* new extension header type.

Peter

-- 
Peter Grimstrup          Systems Developer
Ericsson Telebit A/S     tel: +45 89 38 52 75
Skanderborgvej 232       fax: +45 89 38 51 01
DK 8260 Viby J, Denmark  e-mail: [email-masked]

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 21 Aug 2001 17:19:35 +0200 (CEST)

> I should like to see new header extension types defined in the same
> breathing as the requirement on ordering of all the extension headers.

Currently the Home Address option is sent from MNs to CNs and all CNs must
know how to interpret this in order for communication to work.
(The TCP connection should be identified using the address in the Home Address
option and not the IPv6 source address of the packet, etc).

I think some (I don't know how many) of the shipping IPv6 implementations
do this. I don't know if a sufficiently large number of IPv6 implementations
of CNs will support this to make things interoperate with MIPv6 MNs.

However, if the WG takes the path of putting the information currently in
the Home Address option into the new extension header as you propose,
then some new mechanisms need to be constructed to be able to detect
when a CN doesn't understand the new extension header.
(Note that this is not an issue for the CN not understanding the BU - ignoring
the BU just has the effect of not optimizing the routing.)

A possible way of handling this would be for the MN to notice when it
receives an ICMP parameter problem with code payload type unknown
that the CN might not support it. The the MN, instead of using the 
new extension header to carry the home address, would need to tunnel
the packet through the HA (reverse tunnel).

Of course, if the WG is interested in this level surgery it would also
make sense to seriously consider the proposal that Bill Sommerfeld made
not long ago of replacing the use of routing header and home address option
with just IP in IP encapsulation, perhaps with optimized encapsulation formats
when only one extra IP address is needed in the packet.

   Erik

---

From: Peter Grimstrup <[email-masked]>
Date: Wed, 22 Aug 2001 09:02:37 +0200

Comments inline

> option and not the IPv6 source address of the packet, etc).

Agree.

> the BU just has the effect of not optimizing the routing.)

Points taken, then this in some way boils down to deciding when to comply
to (parts of) draft-xx and when to break (to clean-up etc.)
I havn't been around in this bussiness long enough to judge, but recognize
that maybe more serious questions are awaiting decisions.

---

From: Francis Dupont <[email-masked]>
Date: Wed, 22 Aug 2001 10:43:52 +0200

=> I disagree because this optimization will make BU packets special,
i.e. all other MN->CN packets will carry a visible H@ in a DST header.
If the MN->CN traffic is protected by IPsec this will be a mess.

=> of course! But for Binding Requests?

Regards

[email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Wed, 22 Aug 2001 10:52:10 +0200

=> STOP!!!
This issue was solved at the IETF winter meeting:
 - you can put destination option headers where you'd like
 - NO new intermediate extention header should be defined
 - the advanced API should be updated in order to allow orders
   not in RFC 2460.

Regards