Subject: RE: [mobile-ip] Consensus to include recent piggybacking proposal ?

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Fri, 15 Mar 2002 20:05:16 +0100

Karen Nielsen sent two emails to highlight
the inability to piggyback some RR messages
since they are placed in IPsec tunnels 
by the HA. You can generalise the same 
problem for Security Gateways, in those cases
the MN might not be aware of security policies by
intermediate routers (SGs). 

Also the note was only relevant to IPsec and 
didn't address the QoS issues (e.g. when using 
Diffserv e2e or when having the Diffserv bits
set by intermediate routers). These comments
were explicitly made by David Oran and to some
extent in my earlier emails. 
So I don't think the IPsec issues alone can justify
the introduction of piggybacking in the basic
spec. 

Hesham

  > -----Original Message-----
  > From: Charlie Perkins [mailto:[email-masked]]
  > Sent: Friday, March 15, 2002 8:34 AM
  > To: Mobile IP Working Group
  > Subject: [mobile-ip] Consensus to include recent 
  > piggybacking proposal?
  > 
  > 
  > Hello folks,
  > 
  > A few days ago, I posted a proposal worked out by Jari Malinen,
  > Francis Dupont, and myself that should be a very simple way to
  > eliminate any possible inconsistency between piggybacking and
  > IPsec -- by the simple device of having a "final" Mobility Header
  > and a "nonfinal" Mobility Header, that are otherwise the same.
  > In this way, all possible conflicts with IPsec are removed, and
  > yet endpoints that enable payload with Binding Updates are able
  > to get that performance improvement.
  > 
  > In order to avoid duplicating text, I put the proposal at the
  > following URL:
  >     http://people.nokia.net/charliep/txt/mobilev6/piggybacking.txt
  > 
  > Before this proposal, there was a pretty even split within the
  > working group -- some were for, some against. The main objection
  > seems to center around difficulty with IPsec policy management,
  > and our proposal eliminates that problem entirely.  Thus, I think
  > that we should be able to include this into the base specification,
  > and I am hoping that there will be no one objecting -- because
  > in effect everyone gets what they want!
  > 
  > With this note, I am attempting to gauge consensus on this issue.
  > 
  > Thanks for your consideration of my request.
  > 
  > Regards,
  > Charlie P.
  > 
  > 
  > 
  >

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 15 Mar 2002 11:25:23 -0800

> intermediate routers (SGs).

And I responded to Karen. It is not an issue with the 
current proposal.

Vijay

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 15 Mar 2002 11:47:00 -0800

> intermediate routers (SGs).

This is not an issue with the current proposal,
as Vijay has pointed out.

> extent in my earlier emails.

I responded at length to those e-mails.  There is no
issue with respect to piggybacking and QoS,
_unless_ you are trying to have some sort of
"implicit" QoS without asking for it.  In any
other case, the QoS signalling would trivially
be able to handle any setup required for
deciding whether or not to use piggybacking.

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 15 Mar 2002 11:58:23 -0800

Hello folks,

I forgot to say one other thing:

> deciding whether or not to use piggybacking.

The other point here, is that there is some pretty
heavy channel restriction being proposed to propagate
up the stack, which can easily be construed as
incompatible with IPv6. IPv6 requires minimum MTU
far larger than would interfere with inclusion of a
Binding Update, so all IPv6 nodes MUST be able to
handle such things. Doubly so, since IPv6 nodes have
to be able to parse extension headers in just this way.

Regards,
Charlie P.