Subject: Re: [MOBILE-IP] Comment Please: Placement for Home Address option header

From: Mohan Parthasarathy <[email-masked]>
Date: Fri, 10 Nov 2000 10:48:05 -0800

>
> > > - Putting the information after ESP will make things substantially
> > >    more complicated for possible firewall management.
> >
> > ESP might make firewall management more complicated, I won't
> > dispute that. But my point is that users & admins should have
> > a choice of using AH or ESP. In some environments, the
> > appropriate choice might be ESP. In other environments, AH
> > might be an appropriate choice.
> >
> > If the Home Address option follows an AH header, a firewall
> > can still find it easily. So if you want to be friendly to
> > firewalls, have a policy of using AH. But please don't
> > prevent others from using ESP.
>
> Aha, I just got why you want the Home Address before a Fragment header for
> firewalls: so they can see the Home Address in every packet even fragments.
> Duh. And the Fragment header has to be before the IPsec headers. Since ESP
> isn't friendly to firewalls anyway, firewall-friendliness is only a concern
> for AH. This means two header orders make sense:
> a) IPv6, Home Address, possible Fragment, AH, Binding Update, Transport
> b) IPv6, possible Fragment, ESP (auth and/or encryption), Home Address &
> Binding Update with CoA suboption, Transport
>
Home Address option - a destination option can appear anywhere
and it is not really a destination option anymore :-) Does this
mean RFC2460 needs an update where the recommended order makes
no more sense (Tunnel encapsualtion limit already broke this
some time back).

-mohan

---

From: Francis Dupont <[email-masked]>
Date: Tue, 14 Nov 2000 12:15:10 +0100

In your previous mail you wrote:

=> I *agree*. At the ETSI bake-off discussion many of them asked for
a simplification (destination option header processing is a nightmare).
I already explained my proposal but I *never* got an answer from
an IPv6 person... Can you bring this point to the IPng WG list?

Thanks

[email-masked]