Subject: RE: [mobile-ip] Draft 15

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Tue, 25 Sep 2001 18:30:11 +0200

Hello Charlie, 

> I don't have any problem with getting a new next header unless that
> will somehow introduce (yet!) another delay factor.
> 
	=> I think it's _very_important for us to recognise what the 
	_real_ cause of the delay is. The real cause in terms of security
	was relying on IKE (which needs PKI) as the only key exchange
	mechanism. We've already discussed the use of IPsec for 
	weeks before and after London. 
	I haven't seen any comment suggesting the removal of IPsec, 
	the discussion was whether piggybacking should stay or go. 
	There are several ways of handling the IPsec problem
	I attempted to list some options in the thread titled
	"IPsec, IKE, MIPv6 and concensus" the first message
	was sent on 17th August, you can trace the thread from
	there. 
	Also Jari mentioned that he's documenting these discussoins
	in a draft coming out soon. 

	Hesham

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 25 Sep 2001 10:10:25 -0700

>         in a draft coming out soon.

getting a new next header will cause a delay. this should be pursued
separately and should not be in the MIPv6 spec.

Vijay

---

From: Francis Dupont <[email-masked]>
Date: Wed, 26 Sep 2001 10:33:45 +0200

=> Vijay, we should not do that because the final result will be
two incompatible versions of MIPv6. If we really have a deadline
problem I propose to use UDP port 434 for BU, BA and BR (BRs don't
need security but they are used in a context where BSAs should be
already available so this doesn't matter).
 Of course this will work for IPsec but not with piggybacking so
we have to solve the piggybacking issue first. I propose to relaunch
the multiple payload by packet idea because it is generalization
of piggybacking, so if piggybacking is good this will be even better.
Last draft seems to be draft-kre-ipv6-payload-01.txt. A side effect
of this proposal is to remove the piggybacking issue from the
discussion.

Regards

[email-masked]

PS: references: UDP port 434: RFC 2002 1.9
draft-kre-ipv6-payload-01.txt: I have it, if someone has a public
ftp/http server with a very good connectivity (akamai :-) I'll send
it to him in order to make it available.

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 26 Sep 2001 16:06:15 +0200 (CEST)

> separately and should not be in the MIPv6 spec.

Vijay,

Are you concerned with the delay caused by allocating the next header value
or the delay associated with implementations being modified?

The former delay is zero.
It is addressed by putting text like this in the IANA considerations section
in the spec
	This document requests that the IANA assign an IPv6 next header value
	(which come from the same space as IPv4 protocol numbers)
	for the Binding Update extension header in section X.

Then the IANA will allocate the number before the RFC is published as
proposed standard per the IANA instructions in RFC 2780.

  Erik

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 26 Sep 2001 09:02:41 -0700

Hello Erik,

> proposed standard per the IANA instructions in RFC 2780.

Does this come up for discussion within the IPv6 working group
before IANA approves it?  If so, what do you think would be the
consensus view of that working group?

Regards,
Charlie P.

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 27 Sep 2001 09:54:41 +0200 (CEST)

> consensus view of that working group?

There would at a minimum be an IETF wide last call
at which point anybody can voice their opinion.
I have no ability to guess what opions would be shared.

What is the real question?

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 27 Sep 2001 15:45:01 +0200 (CEST)

> of this proposal is to remove the piggybacking issue from the

It would make sense to check with kre whether he is interested in
pursuing the draft or handing it over to somebody else - at least it
can serve as a starting point.

For instance, it isn't clear whether we need/want the generality of
N payloads per packet or if 2 is sufficient.
The security considerations need work even though kre had work when he
wrote the draft. For instance, understanding the impact on firewalls
that would like to inspect the packets for port numbers.

  Erik

---

From: Charlie Perkins <[email-masked]>
Date: Thu, 27 Sep 2001 07:11:04 -0700

Hello Erik,

That was my question, thanks for answering!

There's a lot of sentiment favoring getting a new
number for Binding Update, and your answer seems
to indicate that it would be unlikely to present much
of a problem.  That means we ought to do that as
part of draft ...-15.

Regards,
Charlie P.

---

From: Francis Dupont <[email-masked]>
Date: Thu, 27 Sep 2001 16:45:38 +0200

=> My intention was to use it as a starting point. I can't see
someting else to do with a draft which expired many years ago.

=> with recursion and no-next-header both are equivalent
(so 2 is sufficient and simpler).

=> I expect the main problem will be the same than for piggybacking
(ambiguity for IPsec selectors, path MTU discovery, ROHC compressor
confusion, etc). But I agree that the possibility to have two (or more)
transport headers will open new perspectives...

Regards

PS: the draft should be available soon on some servers.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 27 Sep 2001 08:16:38 -0700

Hello Francis,

While I agree that both the multi-payload scheme and inserting
Binding Updates into packets with data payloads share the
advantages of reducing the number of packets sent, I think
the similarities stop there.

In particular, it is likely that the multi-payload scheme
would require buffering and delay for previous data packets,
inserting Binding Updates into packets with data payloads
involves checking for recent movement at the time one consults
the route table.  This is quite a bit easier to implement,
and involves no delay.  The receiving end is also quite a
bit easier.

Thus, I think that for the purposes of the present discussion
there should not be any linkage between these two features.

Having said that, however, I do agree that it would be good
idea to enable the delivery of multiple payloads in a single
IPv6 packet, for those applications that can stand the delay.
For major applications of interest to our own research group
here at Nokia, over the next years, I think this delay would
not be tolerable.

Regards,
Charlie P.

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 27 Sep 2001 09:41:52 -0700

Francis Dupont wrote:

> PS: the draft should be available soon on some servers.

heres the URL

http://people.nokia.net/~vijayd/draft-kre-ipv6-payload-01.txt

vijay

---

From: Francis Dupont <[email-masked]>
Date: Thu, 27 Sep 2001 18:49:56 +0200

=> this is not true if collapsed packets are taken from the
sending queue (*). I believe a similar mechanism (super-framing?)
is done on very fast links where media acquisition is expensive.

=> I agree but your argument is only for not smart enough
implementations of multi-payload (not of BU piggybacking).

=> is your opinion based mainly on the delay argument?

Thanks

PS: the counter-argument is by Laurent Toutain (I suggested
that to wait to get enough payloads before to send a large
packet is not the best idea of the year).

---

From: "Jari Arkko" <[email-masked]>
Date: Thu, 27 Sep 2001 21:27:44 +0300

Hi Charlie,

> and involves no delay.  The receiving end is also quite a

I suppose the above depends on how the 'merge' operation
is viewed. If it is seen as a general purpose packet merger
looking at outgoing packets, then it would need to see two
packets before doing a merge, implying buffer. However, this
may not be necessary. You might also implement the receiver
side in a general manner, but have a specific trigger on the
sending side when to do a merge. For instance, when your
implementation now would construct a piggybacked BU, it
appears that it should be able to construct a merged packet
in the similar manner and without a delay. 

However, one concern I have with the general solution is
that I'm not quite sure how it would be deployed in a world
where not all (obviously!) nodes support this. How would an
MN know the receiver supports this? Through a trial-and-ICMP?
Or try once and if you get an ack, then use towards that host
also in the future?

Jari

---

From: Charlie Perkins <[email-masked]>
Date: Thu, 27 Sep 2001 12:26:23 -0700

Hello Jari,

> > and involves no delay.  The receiving end is also quite a

I see that I didn't type this correctly.  'inserting Binding Update'
should be the start of a new sentence.  As it is, I reckon that
it would be easy to misinterpret what I meant.

Regards,
Charlie P.