issue 93 summary

 > > => Right, we don't need it and we can't have
it anyway.
 > 
 > No. We can still have TLV header. But, I'm saying we
have a
 > protocol qualifier. I thought, it might be better to
avoid
 > atleast for ESP, but, Vijay was suggesting why not
have it
 > consistently for all modes ESP or non-ESP modes. This
is
 > how the implementation will work:
 > 
 > I define tunnel interface with the encap mode of
IPv4-UDP-TLV.
 > Now, I apply crypto policy on this interface. All
packets
 > GRE, IPv4, IPv6 packets when sent through this
interface, will
 > get hit the crypto policy and get the ESP header. As
the packets
 > are routed, the tunnel interface will apply the
IPv4-UDP-TLV
 > header.  For incomming packets, the packets will match
the
 > tunnel interface, crypto policy check will remove the
ESP
 > header and identify the payloads using the payload
qualifier
 > in the "next header" field of the ESP
header. This is one
 > way of implementation.
 > 
 > With ESP, TLV heeader points to ESP:
 > IPv4-UDP {TLV {ESP (IPv4, IPv6)}}

=> Do you agree that this is not 3948? The reason we
opened this issue was
Karen's question about how we'd use 3948 which defines UDP
ESP
encapsulation. If you run this format on port 4500 then it
obviously won't
work. Do you also agree now (given your earlier email) that
this is only an
issue for option 3 and not 2 and 1? 


 > Like I said, we can get some input from the IPSec
folks
 > on this, if you disagree with this.

=> I don't understand what input you are seeking, this is
a different format
from the RFC so if you run it on the same port with an
implementation of
that RFC then it won't work. What am I missing? 

 > 
 > We can also avoid TLV header all together, when using
ESP.
 > We can carry all protocol types.

=> I think we'll have to. I don't get this "either
or" description. Also
adding and removing the TLV field based on whether ESP is
used or not
doesn't seem to be a good way of doing things because it
introduces a
dependency between the mobility implementation and the way
IPsec is being
used. 

 > > => Nope. We have requirements from MIP6 and
NEMO. Of course 
 > > it's nice if we
 > > can help any other work (including PMIP) if we
can, but I 
 > > think it's wrong
 > > to do that at the cost of making the base spec
worse for its 
 > > primary users.
 > > If PMIP needs extensions (and it does in other
cases) then it 
 > > can extend
 > > those solutions for its own use and still
reference this 
 > > work. We shouldn't
 > > burden the base for the case of PMIP, especially
when PMIP 
 > > was never the
 > > main user of this work.
 > > 
 > >  But, I
 > >  > agree, GRE may not be required for a normal
MIP6 tunnel.
 > > 
 > > => Great. So I think at least we're making
progress in 
 > > understanding where
 > > this is perceived to be needed. The question is
whether it 
 > > needs to be done
 > > here or in NETLMM where the beneficiary is. I
don't think 
 > we should be
 > > addressing it here. 
 > 
 > 
 > I think, we can certainly avoid GRE in DSMIP, if we
really want
 > to ignore that requirement. There are valid use cases
that are
 > there for NETLMM, MIP6 and NEMO, we can solve with a
tiny header.
 > As Yoshi pointed out, if some one wants to tunnel
legacy IPX
 > or other traffic from the MN to home network, GRE is
required.

=> You mean you can't carry IPX in IP using proto 111? If
a node does not
implement IP at all then we're not talking about an MN. If
the MR want to
tunnel IPX in IP then that would work too. 
I understand you might prefer GRE, but there is a difference
between a MUST
and a MAY type goal. A MAY type goal need not be in the base
and force
everyone else to use it. A MUST goal has to be in the base.


I'm a bit sceptical about unexplained scenarios that come
piecemeal. If you
have a scenario in mind where this is needed for the MR/MN
then please write
it down. I find it difficult to keep up with the discussion
when each email
contradicts the one before it. In the last email you said
you wanted this
for PMIP and MIPv6 didn't need it. Now it's a different
story. It's hard for
me to discuss things this way.

Hesham

>  > No. We can still have TLV header. But, I'm saying
we have a
>  > protocol qualifier. I thought, it might be better
to avoid
>  > atleast for ESP, but, Vijay was suggesting why
not have it
>  > consistently for all modes ESP or non-ESP modes.
This is
>  > how the implementation will work:
>  > 
>  > I define tunnel interface with the encap mode of
IPv4-UDP-TLV.
>  > Now, I apply crypto policy on this interface. All
packets
>  > GRE, IPv4, IPv6 packets when sent through this
interface, will
>  > get hit the crypto policy and get the ESP header.
As the packets
>  > are routed, the tunnel interface will apply the
IPv4-UDP-TLV
>  > header.  For incomming packets, the packets will
match the
>  > tunnel interface, crypto policy check will remove
the ESP
>  > header and identify the payloads using the
payload qualifier
>  > in the "next header" field of the ESP
header. This is one
>  > way of implementation.
>  > 
>  > With ESP, TLV heeader points to ESP:
>  > IPv4-UDP {TLV {ESP (IPv4, IPv6)}}
> 
> => Do you agree that this is not 3948? 

Yes, it is not 3948.

> The reason we opened 
> this issue was
> Karen's question about how we'd use 3948 which defines
UDP ESP
> encapsulation. If you run this format on port 4500 then
it 
> obviously won't
> work. Do you also agree now (given your earlier email)
that 
> this is only an
> issue for option 3 and not 2 and 1? 

Port 4500 will not be used. The UDP port number will point
to the
TLV and the TLV will say ESP follows.

Vijay

> 
> 
>  > Like I said, we can get some input from the IPSec
folks
>  > on this, if you disagree with this.
> 
> => I don't understand what input you are seeking,
this is a 
> different format
> from the RFC so if you run it on the same port with an

> implementation of
> that RFC then it won't work. What am I missing? 
> 
>  > 
>  > We can also avoid TLV header all together, when
using ESP.
>  > We can carry all protocol types.
> 
> => I think we'll have to. I don't get this
"either or" 
> description. Also
> adding and removing the TLV field based on whether ESP
is used or not
> doesn't seem to be a good way of doing things because
it introduces a
> dependency between the mobility implementation and the
way 
> IPsec is being
> used. 
> 
>  > > => Nope. We have requirements from MIP6
and NEMO. Of course 
>  > > it's nice if we
>  > > can help any other work (including PMIP) if
we can, but I 
>  > > think it's wrong
>  > > to do that at the cost of making the base
spec worse for its 
>  > > primary users.
>  > > If PMIP needs extensions (and it does in
other cases) then it 
>  > > can extend
>  > > those solutions for its own use and still
reference this 
>  > > work. We shouldn't
>  > > burden the base for the case of PMIP,
especially when PMIP 
>  > > was never the
>  > > main user of this work.
>  > > 
>  > >  But, I
>  > >  > agree, GRE may not be required for a
normal MIP6 tunnel.
>  > > 
>  > > => Great. So I think at least we're
making progress in 
>  > > understanding where
>  > > this is perceived to be needed. The question
is whether it 
>  > > needs to be done
>  > > here or in NETLMM where the beneficiary is.
I don't think 
>  > we should be
>  > > addressing it here. 
>  > 
>  > 
>  > I think, we can certainly avoid GRE in DSMIP, if
we really want
>  > to ignore that requirement. There are valid use
cases that are
>  > there for NETLMM, MIP6 and NEMO, we can solve
with a tiny header.
>  > As Yoshi pointed out, if some one wants to tunnel
legacy IPX
>  > or other traffic from the MN to home network, GRE
is required.
> 
> => You mean you can't carry IPX in IP using proto
111? If a 
> node does not
> implement IP at all then we're not talking about an MN.
If 
> the MR want to
> tunnel IPX in IP then that would work too. 
> I understand you might prefer GRE, but there is a
difference 
> between a MUST
> and a MAY type goal. A MAY type goal need not be in the
base and force
> everyone else to use it. A MUST goal has to be in the
base. 
> 
> I'm a bit sceptical about unexplained scenarios that
come 
> piecemeal. If you
> have a scenario in mind where this is needed for the
MR/MN 
> then please write
> it down. I find it difficult to keep up with the
discussion 
> when each email
> contradicts the one before it. In the last email you
said you 
> wanted this
> for PMIP and MIPv6 didn't need it. Now it's a different

> story. It's hard for
> me to discuss things this way.
> 
> Hesham
> 
> 
> 
> 

Hesham:



On Fri, 8 Jun 2007, Hesham Soliman wrote:

>
> => Do you agree that this is not 3948? The reason we
opened this issue was
> Karen's question about how we'd use 3948 which defines
UDP ESP
> encapsulation. If you run this format on port 4500 then
it obviously won't
> work. Do you also agree now (given your earlier email)
that this is only an
> issue for option 3 and not 2 and 1?
>

I'm again saying, we need a protocol qualifier. That is the
title of the issue. We just need a way to identify the
payload
that is carried in a UDP header. ESP provides that and we
dont
need the TLV for that mode. When ESP is not there, we need
the TLV header. Now, with respect to 3948, if it does not
permit TLV on top of UDP, fine. No issue, as we dont need
it.
If using TLV after UDP is not 3948, as Vijay says, I agree.
We dont have to use the TLV for that mode.


>
> > Like I said, we can get some input from the IPSec
folks
> > on this, if you disagree with this.
>
> => I don't understand what input you are seeking,
this is a different format
> from the RFC so if you run it on the same port with an
implementation of
> that RFC then it won't work. What am I missing?
>
> >
> > We can also avoid TLV header all together, when
using ESP.
> > We can carry all protocol types.
>
> => I think we'll have to. I don't get this
"either or" description. Also
> adding and removing the TLV field based on whether ESP
is used or not
> doesn't seem to be a good way of doing things because
it introduces a
> dependency between the mobility implementation and the
way IPsec is being
> used.

I disagree. We can skip the encap, if its not required.


>
> => You mean you can't carry IPX in IP using proto
111? If a node does not
> implement IP at all then we're not talking about an MN.
If the MR want to
> tunnel IPX in IP then that would work too.
> I understand you might prefer GRE, but there is a
difference between a MUST
> and a MAY type goal. A MAY type goal need not be in the
base and force
> everyone else to use it. A MUST goal has to be in the
base.
>

Its not about preference. When using IPv4-UDP tunnel, to
carry IPX
or other payloads, we need GRE. If there is no NAT, I've no
issue,
GRE can be carried in IPv4, IPv6.

> I'm a bit sceptical about unexplained scenarios that
come piecemeal. If you
> have a scenario in mind where this is needed for the
MR/MN then please write
> it down. I find it difficult to keep up with the
discussion when each email
> contradicts the one before it. In the last email you
said you wanted this
> for PMIP and MIPv6 didn't need it. Now it's a different
story. It's hard for
> me to discuss things this way.
>

Lets hear from others. Its my word against your word. We
both know
exactly what the requirements are and why this is required
not
required.

Sri

> How do you envisage to negotiate the ESP SA for 
> 
> IPv4-UDP {TLV {ESP (IPv4, IPv6)}} - ??

You negotiate as if you are negotiating for NAT traversal.

> - and should IP Sec now be made to understand
> Ipv4 UDP TVL ESP encapsulation - Or how do you intend
to trick
> IPSec to respectively decrypt and extract and encrypt
and 
> insert the ESP
> header ?

The IPsec implementation shouldn't have to insert the TLV.
It would
be done by Mobile IPv6. (similar to how Mobile IPv6 inserts
the 
home address option after IPsec is done with adding the ESP
header).

> In our "fast" IP stack implementation we use
4500 UDP port number
> scanning to intercept
> UDP ESP packets for IPSec processing.
> Option 2 with a specified port for IPv4/IPv6 would be a

> straightforward
> extension of this.
> Option 1 and Option 3 both require scanning of the UDP
payload for ALL
> UDP packets. As a starting point
> this does not seem very nice.

You don't have to scan for all UDP ports. Your
"fast" IP stack
implementation, in addition to port 4500, would need to look
for 
the UDP port that points to the TLV and the TLV
port/protocol 
field that identifies ESP.

Vijay

> 
> Karen 
> 
> > -----Original Message-----
> > From: Vijay Devarapalli
[mailto:Vijay.DevarapalliAzaireNet.com] 
> > Sent: 8. juni 2007 04:15
> > To: Hesham Soliman; Sri Gundavelli; Karen E.
Nielsen 
> > (AH/LMD); Alexandru Petrescu
> > Cc: nemoietf.org; mip6ietf.org
> > Subject: RE: [nemo] RE: [Mip6] issue 93 summary
> > 
> > >  > No. We can still have TLV header. But,
I'm saying we have a  > 
> > > protocol qualifier. I thought, it might be
better to avoid  
> > > atleast 
> > > for ESP, but, Vijay was suggesting why not
have it  > 
> > consistently for 
> > > all modes ESP or non-ESP modes. This is  >
how the 
> > implementation will 
> > > work:
> > >  >
> > >  > I define tunnel interface with the
encap mode of IPv4-UDP-TLV.
> > >  > Now, I apply crypto policy on this
interface. All 
> > packets  > GRE, 
> > > IPv4, IPv6 packets when sent through this
interface, will  
> > > get hit 
> > > the crypto policy and get the ESP header. As
the packets  > are 
> > > routed, the tunnel interface will apply the
IPv4-UDP-TLV  > 
> > header.  
> > > For incomming packets, the packets will match
the  > tunnel 
> > interface, 
> > > crypto policy check will remove the ESP  >
header and 
> identify the 
> > > payloads using the payload qualifier  > in
the "next 
> > header" field of 
> > > the ESP header. This is one  > way of
implementation.
> > >  >
> > >  > With ESP, TLV heeader points to ESP:
> > >  > IPv4-UDP {TLV {ESP (IPv4, IPv6)}}
> > > 
> > > => Do you agree that this is not 3948? 
> > 
> > Yes, it is not 3948.
> > 
> > > The reason we opened
> > > this issue was
> > > Karen's question about how we'd use 3948
which defines UDP ESP 
> > > encapsulation. If you run this format on port
4500 then it 
> > obviously 
> > > won't work. Do you also agree now (given your
earlier 
> > email) that this 
> > > is only an issue for option 3 and not 2 and
1?
> > 
> > Port 4500 will not be used. The UDP port number
will point to 
> > the TLV and the TLV will say ESP follows.
> > 
> > Vijay
> > 
> > > 
> > > 
> > >  > Like I said, we can get some input from
the IPSec folks  
> > > on this, 
> > > if you disagree with this.
> > > 
> > > => I don't understand what input you are
seeking, this is a 
> > different 
> > > format from the RFC so if you run it on the
same port with an 
> > > implementation of that RFC then it won't
work. What am I missing?
> > > 
> > >  >
> > >  > We can also avoid TLV header all
together, when using ESP.
> > >  > We can carry all protocol types.
> > > 
> > > => I think we'll have to. I don't get this
"either or" 
> > > description. Also
> > > adding and removing the TLV field based on
whether ESP is 
> > used or not 
> > > doesn't seem to be a good way of doing things
because it 
> > introduces a 
> > > dependency between the mobility
implementation and the 
> way IPsec is 
> > > being used.
> > > 
> > >  > > => Nope. We have requirements
from MIP6 and NEMO. Of 
> > course  > > 
> > > it's nice if we  > > can help any other
work (including 
> PMIP) if we 
> > > can, but I  > > think it's wrong  >
> to do that at the 
> > cost of making 
> > > the base spec worse for its  > >
primary users.
> > >  > > If PMIP needs extensions (and it
does in other cases) 
> > then it  > 
> > > > can extend  > > those solutions
for its own use and still 
> > reference 
> > > this  > > work. We shouldn't  > >
burden the base for the case of 
> > > PMIP, especially when PMIP  > > was
never the  > > main 
> > user of this 
> > > work.
> > >  > >
> > >  > >  But, I
> > >  > >  > agree, GRE may not be
required for a normal MIP6 tunnel.
> > >  > >
> > >  > > => Great. So I think at least
we're making progress in  > > 
> > > understanding where  > > this is
perceived to be needed. 
> > The question 
> > > is whether it  > > needs to be done 
> > here or in NETLMM 
> > where the 
> > > beneficiary is. I don't think  > we should
be  > > 
> > addressing it here.
> > >  >
> > >  >
> > >  > I think, we can certainly avoid GRE in
DSMIP, if we 
> > really want  > 
> > > to ignore that requirement. There are valid
use cases that are  > 
> > > there for NETLMM, MIP6 and NEMO, we can solve
with a tiny header.
> > >  > As Yoshi pointed out, if some one wants
to tunnel legacy 
> > IPX  > or 
> > > other traffic from the MN to home network,
GRE is required.
> > > 
> > > => You mean you can't carry IPX in IP
using proto 111? If a 
> > node does 
> > > not implement IP at all then we're not
talking about an MN. 
> > If the MR 
> > > want to tunnel IPX in IP then that would work
too.
> > > I understand you might prefer GRE, but there
is a 
> > difference between a 
> > > MUST and a MAY type goal. A MAY type goal
need not be in 
> > the base and 
> > > force everyone else to use it. A MUST goal
has to be in the base.
> > > 
> > > I'm a bit sceptical about unexplained
scenarios that come 
> > piecemeal. 
> > > If you have a scenario in mind where this is
needed for the 
> > MR/MN then 
> > > please write it down. I find it difficult to
keep up with the 
> > > discussion when each email contradicts the
one before it. 
> > In the last 
> > > email you said you wanted this for PMIP and
MIPv6 didn't 
> > need it. Now 
> > > it's a different story. It's hard for me to
discuss 
> things this way.
> > > 
> > > Hesham
> > > 
> > > 
> > > 
> > > 
> > 
> 

 
> Thanks! I understand the port scanning issue 
> as well as the insertion/extraction of TLV
> header much better now. Sorry to have caused any
confusion.
> 
> So would it be correct to say that the real difference
IPSec-wise,
> in-between 
> option 1,2 and option 3 is that with option 3, then
logically 
> MIP need 
> "to come in" before inbound and after
outbound IPSec processing 
> to extract/insert TLV and update length fields.
> Whereas this is not the case with option 1 and 2.

Yes. The TVL would be added for all packets that are sent
through 
a tunnel setup by DS-MIPv6, when the mobile node is on an
IPv4 
access network.

> 
> As it is also not the case in standard MIPv6 with IPSec

> tunneling to HA.

Well, we kind of have tighter integration between MIPv6 and
IPsec
already. For e.g, the insertation of home address option and

routing header is done by MIPv6 after IPsec processing is
done. 
The use of 'K' bit (to update the tunnel end point) also
requires
this. I am not suggesting we continue doing this, but adding
TLV
shouldn't be a big issue. 

Vijay

> 
> Karen
> 
> > -----Original Message-----
> > From: Vijay Devarapalli
[mailto:Vijay.DevarapalliAzaireNet.com] 
> > Sent: 8. juni 2007 20:04
> > To: Karen E. Nielsen (AH/LMD); Hesham Soliman; Sri

> > Gundavelli; Alexandru Petrescu
> > Cc: nemoietf.org; mip6ietf.org
> > Subject: RE: [nemo] RE: [Mip6] issue 93 summary
> > 
> > > How do you envisage to negotiate the ESP SA
for
> > > 
> > > IPv4-UDP {TLV {ESP (IPv4, IPv6)}} - ??
> > 
> > You negotiate as if you are negotiating for NAT
traversal.
> > 
> > > - and should IP Sec now be made to
understand
> > > Ipv4 UDP TVL ESP encapsulation - Or how do
you intend to 
> > trick IPSec 
> > > to respectively decrypt and extract and
encrypt and 
> insert the ESP 
> > > header ?
> > 
> > The IPsec implementation shouldn't have to insert
the TLV. It 
> > would be done by Mobile IPv6. (similar to how
Mobile IPv6 
> > inserts the home address option after IPsec is
done with 
> > adding the ESP header).
> > 
> > > In our "fast" IP stack
implementation we use 4500 UDP port number 
> > > scanning to intercept UDP ESP packets for
IPSec processing.
> > > Option 2 with a specified port for IPv4/IPv6
would be a 
> > > straightforward extension of this.
> > > Option 1 and Option 3 both require scanning
of the UDP 
> > payload for ALL 
> > > UDP packets. As a starting point this does
not seem very nice.
> > 
> > You don't have to scan for all UDP ports. Your
"fast" IP 
> > stack implementation, in addition to port 4500,
would need to 
> > look for the UDP port that points to the TLV and
the TLV 
> > port/protocol field that identifies ESP.
> > 
> > Vijay
> > 
> > > 
> > > Karen
> > > 
> > > > -----Original Message-----
> > > > From: Vijay Devarapalli
[mailto:Vijay.DevarapalliAzaireNet.com]
> > > > Sent: 8. juni 2007 04:15
> > > > To: Hesham Soliman; Sri Gundavelli;
Karen E. Nielsen (AH/LMD); 
> > > > Alexandru Petrescu
> > > > Cc: nemoietf.org; mip6ietf.org
> > > > Subject: RE: [nemo] RE: [Mip6] issue 93
summary
> > > > 
> > > > >  > No. We can still have TLV
header. But, I'm saying we 
> > have a  > 
> > > > > protocol qualifier. I thought, it
might be better to 
> > avoid atleast 
> > > > > for ESP, but, Vijay was suggesting
why not have it  >
> > > > consistently for
> > > > > all modes ESP or non-ESP modes.
This is  > how the
> > > > implementation will
> > > > > work:
> > > > >  >
> > > > >  > I define tunnel interface
with the encap mode of 
> > IPv4-UDP-TLV.
> > > > >  > Now, I apply crypto policy on
this interface. All
> > > > packets  > GRE,
> > > > > IPv4, IPv6 packets when sent
through this interface, 
> > will get hit 
> > > > > the crypto policy and get the ESP
header. As the 
> packets  > are 
> > > > > routed, the tunnel interface will
apply the IPv4-UDP-TLV  >
> > > > header.  
> > > > > For incomming packets, the packets
will match the  > tunnel
> > > > interface,
> > > > > crypto policy check will remove the
ESP  > header and
> > > identify the
> > > > > payloads using the payload
qualifier  > in the "next
> > > > header" field of
> > > > > the ESP header. This is one  >
way of implementation.
> > > > >  >
> > > > >  > With ESP, TLV heeader points
to ESP:
> > > > >  > IPv4-UDP {TLV {ESP (IPv4,
IPv6)}}
> > > > > 
> > > > > => Do you agree that this is not
3948? 
> > > > 
> > > > Yes, it is not 3948.
> > > > 
> > > > > The reason we opened
> > > > > this issue was
> > > > > Karen's question about how we'd use
3948 which 
> defines UDP ESP 
> > > > > encapsulation. If you run this
format on port 4500 then it
> > > > obviously
> > > > > won't work. Do you also agree now
(given your earlier
> > > > email) that this
> > > > > is only an issue for option 3 and
not 2 and 1?
> > > > 
> > > > Port 4500 will not be used. The UDP port
number will 
> point to the 
> > > > TLV and the TLV will say ESP follows.
> > > > 
> > > > Vijay
> > > > 
> > > > > 
> > > > > 
> > > > >  > Like I said, we can get some
input from the IPSec folks on 
> > > > > this, if you disagree with this.
> > > > > 
> > > > > => I don't understand what input
you are seeking, this is a
> > > > different
> > > > > format from the RFC so if you run
it on the same port with an 
> > > > > implementation of that RFC then it
won't work. What am 
> > I missing?
> > > > > 
> > > > >  >
> > > > >  > We can also avoid TLV header
all together, when using ESP.
> > > > >  > We can carry all protocol
types.
> > > > > 
> > > > > => I think we'll have to. I
don't get this "either or" 
> > > > > description. Also
> > > > > adding and removing the TLV field
based on whether ESP is
> > > > used or not
> > > > > doesn't seem to be a good way of
doing things because it
> > > > introduces a
> > > > > dependency between the mobility
implementation and the
> > > way IPsec is
> > > > > being used.
> > > > > 
> > > > >  > > => Nope. We have
requirements from MIP6 and NEMO. Of
> > > > course  > >
> > > > > it's nice if we  > > can help
any other work (including
> > > PMIP) if we
> > > > > can, but I  > > think it's
wrong  > > to do that at the
> > > > cost of making
> > > > > the base spec worse for its  >
> primary users.
> > > > >  > > If PMIP needs extensions
(and it does in other cases)
> > > > then it  >
> > > > > > can extend  > > those
solutions for its own use and still
> > > > reference
> > > > > this  > > work. We shouldn't 
> > burden the base for 
> > the case of 
> > > > > PMIP, especially when PMIP  >
> was never the  > > main
> > > > user of this
> > > > > work.
> > > > >  > >
> > > > >  > >  But, I
> > > > >  > >  > agree, GRE may not
be required for a normal 
> MIP6 tunnel.
> > > > >  > >
> > > > >  > > => Great. So I think
at least we're making 
> > progress in  > > 
> > > > > understanding where  > > this
is perceived to be needed.
> > > > The question
> > > > > is whether it  > > needs to
be done  > > here or in NETLMM
> > > > where the
> > > > > beneficiary is. I don't think  >
we should be  > >
> > > > addressing it here.
> > > > >  >
> > > > >  >
> > > > >  > I think, we can certainly
avoid GRE in DSMIP, if we
> > > > really want  >
> > > > > to ignore that requirement. There
are valid use cases 
> > that are  > 
> > > > > there for NETLMM, MIP6 and NEMO, we
can solve with a 
> > tiny header.
> > > > >  > As Yoshi pointed out, if some
one wants to tunnel legacy
> > > > IPX  > or
> > > > > other traffic from the MN to home
network, GRE is required.
> > > > > 
> > > > > => You mean you can't carry IPX
in IP using proto 111? If a
> > > > node does
> > > > > not implement IP at all then we're
not talking about an MN. 
> > > > If the MR
> > > > > want to tunnel IPX in IP then that
would work too.
> > > > > I understand you might prefer GRE,
but there is a
> > > > difference between a
> > > > > MUST and a MAY type goal. A MAY
type goal need not be in
> > > > the base and
> > > > > force everyone else to use it. A
MUST goal has to be in 
> > the base.
> > > > > 
> > > > > I'm a bit sceptical about
unexplained scenarios that come
> > > > piecemeal. 
> > > > > If you have a scenario in mind
where this is needed for the
> > > > MR/MN then
> > > > > please write it down. I find it
difficult to keep up with the 
> > > > > discussion when each email
contradicts the one before it.
> > > > In the last
> > > > > email you said you wanted this for
PMIP and MIPv6 didn't
> > > > need it. Now
> > > > > it's a different story. It's hard
for me to discuss
> > > things this way.
> > > > > 
> > > > > Hesham
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 

Hi Karen, 

> -----Original Message-----
> From: Karen E. Nielsen (AH/LMD)
[mailto:karen.e.nielsenericsson.com] 
> Sent: Saturday, June 09, 2007 4:28 AM
> To: Vijay Devarapalli; Hesham Soliman; Sri Gundavelli;

> Alexandru Petrescu
> Cc: nemoietf.org; mip6ietf.org
> Subject: RE: [nemo] RE: [Mip6] issue 93 summary
> 
> Hi,
> 
>  
> > 
> > > 
> > > As it is also not the case in standard MIPv6
with IPSec 
> > tunneling to 
> > > HA.
> > 
> > Well, we kind of have tighter integration between
MIPv6 and 
> > IPsec already. For e.g, the insertation of home
address 
> > option and routing header is done by MIPv6 after
IPsec 
> > processing is done. 
> > The use of 'K' bit (to update the tunnel end
point) also 
> > requires this. I am not suggesting we continue
doing this, 
> > but adding TLV shouldn't be a big issue. 
> > 
> > Vijay
> > 
> 
> Yes, . I do not
want to be twisting straws here about the pros and
> cons. I
> am simply trying to understand the differences.
> 
> However, (now you may see this as twisting straws, but
the angle is
> different),
> the extraction and insertion of RH/DO is a mobility
thing and 
> there is a
> very good reason
> IPSec shouldn't know about those as we exactly want the
movement to be
> transparent to
> IPSec SAs anchored on the MN's home address.
> 
> The TLV header is not a mobility thing, per se, as I
understand it. 
> So the insertion and extraction outside IPSec seems
more like 
> a hack to
> allow this
> new encapsulation header type IP-UDP-TLV to use IPSec
UDP ESP
> encapsulation. 
> 
> I agree that it is feasible from an implementation
perspective. 
> It is not a very nice, though. But perhaps need is a
better keyword,
> than nice here.
> 

When 3948 is used, ie if the port is 4500 and not DSMIP
port, the TLV
header is not required, as we can carry other protocol
payloads and
the required headers are present for that mode. So, the
behaviour is
consistent to 3948 and its the same for both option#1 and
option#3.

If we prefer both the ESP and non ESP traffic to be handled
as a 
IP-UDP-TLV traffic on DSMIP port, the MIP is the handler for
this
traffic and will remove the tunnel encapsulations and pass
it the the
IPSec process. So, its about the registered handlers, IPSec
is the
handler on 4500 and MIP on the DSMIP port. MIP understands
all the
encapsulation formats and hence can do the proper decaps and
pass
it to the crypto system. 

Sri 

 
> > > As it is also not the case in standard MIPv6
with IPSec 
> > tunneling to 
> > > HA.
> > 
> > Well, we kind of have tighter integration between
MIPv6 and 
> > IPsec already. For e.g, the insertation of home
address 
> > option and routing header is done by MIPv6 after
IPsec 
> > processing is done. 
> > The use of 'K' bit (to update the tunnel end
point) also 
> > requires this. I am not suggesting we continue
doing this, 
> > but adding TLV shouldn't be a big issue. 
> > 
> > Vijay
> > 
> 
> Yes, . I do not
want to be twisting straws here about the pros and
> cons. I
> am simply trying to understand the differences.
> 
> However, (now you may see this as twisting straws, but
the angle is
> different),
> the extraction and insertion of RH/DO is a mobility
thing and there is a
> very good reason
> IPSec shouldn't know about those as we exactly want the
movement to be
> transparent to
> IPSec SAs anchored on the MN's home address.
> 
> The TLV header is not a mobility thing, per se, as I
understand it. 
> So the insertion and extraction outside IPSec seems
more like a hack to
> allow this
> new encapsulation header type IP-UDP-TLV to use IPSec
UDP ESP
> encapsulation. 

Well, the TLV is specific to DS-MIPv6 tunnels setup over
IPv4. 
No other protocol is using the TLV. 

Vijay

> 
> I agree that it is feasible from an implementation
perspective. 
> It is not a very nice, though. But perhaps need is a
better keyword,
> than nice here.
> 
> Karen
> 
> 
> 
>