Subject: RE: [Mip6] draft-soliman and draft-wakikawa

From: "Soliman, Hesham" <[email-masked]>
Date: Fri, 1 Apr 2005 19:45:41 -0500

> > => Correct in the scenario you mentioned. This draft also
 > > supports another scenario: using IPv4 home address and
 > > IPv6 CoA. 
 > 
 > which we are not interested in and out of scope for this
 > discussion.

=> Who decided it's out of scope?? This is what we should be 
discussing...

Hesham

===========================================================
This email may contain confidential and privileged material for the sole use
 of the intended recipient.  Any review or distribution by others is strictly
 prohibited.  If you are not the intended recipient please contact the sender
 and delete all copies.
===========================================================

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: Gerardo Giaretta <[email-masked]>
Date: Mon, 04 Apr 2005 16:22:20 +0200

Hi Ryuji,

please see below..

> > Hi Vijay,
> >
> > please see below..
> >
> >>
> >> Gerardo, Keiichi, Hesham and Henrik,
> >>
> >> draft-soliman and draft-wakikawa both talk about binding a v4
> >> CoA to a v6 HoA and setting an IPv6 over IPv4 tunnel between
> >> the MN and the HA. the difference is in the way, the CoA is
> >> conveyed to the HA. draft-soliman uses IPv4 mapped IPv6
> >> address as the source address in the inner header. I believe
> >> the packet format looks like the following.
> >>
> >>    IPv4 hdr (src=CoA_v4, dst=HA_v4)
> >>    IPv6 hdr (src=v4-mapped-v6-CoA, dst=HA_v6)
> >>    Dst opts hdr
> >>        HoA_v6
> >>    Mobility hdr
> >>        Binding Update
> >>
> >> Hesham, let me know if this is not correct?
> >>
> >> the HA extracts the IPv4 address from the v4-mapped-v6-CoA.
> >>
> >> draft-wakikawa uses a mobility option for carrying the IPv4
> >> address.
> >>
> >>    IPv4 hdr (src=CoA_v4, dst=HA_v4)
> >>    IPv6 hdr (src=HoA_v6, dst=HA_v6)
> >>    Mobility hdr
> >>        Binding Update
> >>            IPv4 CoA mobility option
> >>
> >> this is the main difference.
> >>
> >> apart from this, is there is anything else in draft-soliman
> >> that you think is important for the specific scenario we are
> >> talking about (v6 MN/MR accessing v6 HA from a v4 only access
> >> network).
> >>
> >> draft-wakikawa, OTOH, also talks about the following. detailed
> >> MN and HA behavior, IPsec SPD and SAD entries for securing the
> >> IPv6-over-IPv4 tunnel, NAT traversal, how to negotiate a
> >> particular tunneling mechanism and new binding ack status
> >> values.
> >>
> >> personally, I prefer a new mobility option to carry the IPv4
> >> CoA, because it makes processing on the HA simple. but we can
> >> have the WG decide on this. I am open.
> >>
> >
> > my point was that I'd like to understand the rationale behind this
> > choice (is it only that it makes processing on HA simpler? 
> how do you
> > measure this simpleness?). As stated before, I'm not adovacting any
> > draft, just trying to understand the best approach to 
> register a IPv4
> > CoA. However, I think this is a secondary issue and we 
> should address 
> > it
> > after we all agree on the scenario(s) to be considered.
> 
> Hello Gerardo
> 
> Supporting NAT traversal or not.

ok 

> For mobile node, it's simpler to clear out MIP6 tunnel and use v4-v6 
> tunnel.
> It also removes HoA option from packets while MN is in Ipv4 networks.

could you clarify this please?

> IPsec protection is also different. In our draft, MN 
> establishes SA for 
> IPv4 addresses.
> 

Based on rfc3776 and draft-ietf-mip6-ikev2-ipsec-01, the SA must be
created for the HoA, that is always an IPv6 address in your scenario.
So, what do you mean by "MN establishes SA for IPv4 adresses"?

Regards,
--Gerardo

> what else..
> regards,
> ryuji
> > --Gerardo
> >> Vijay
> > Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia 
> > S.p.A.
> >
> > ====================================================================
> > CONFIDENTIALITY NOTICE
> > This message and its attachments are addressed solely to the persons
> > above and may contain confidential information. If you have received
> > the message in error, be informed that any use of the content hereof
> > is prohibited. Please return it immediately to the sender and delete
> > the message. Should you have any questions, please send an e_mail to
> > [email-masked]. Thank you
> > ====================================================================
> >

Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A.

====================================================================
CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please send an e_mail to 
[email-masked]. Thank you
====================================================================

---

From: "Soliman, Hesham" <[email-masked]>
Date: Mon, 4 Apr 2005 11:24:02 -0400

> >> Whoops!  You individually may not be interested in it, but
 > >> I individually do - and I see no reason why this should be
 > >> out of scope for this discussion.
 > > 
 > > I individually don't.
 > > Using MIPv4 in IPv6 networks should be discussed in MIPv4 WG.
 > 
 > I didn't interpret Hesham's statement as being about MIPv4.
 > There is a separate draft (draft-tsirtsis-v4v6-mipv4-00.txt)
 > from the same authors which cover mip4.

=> Exactly, I wasn't talking about MIP4.I was talking about having 
an IPv4 HoA, IPv6 CoA and using MIP6. 

Hesham

 > 
 > However I agree that if this was the case, it wouldn't belong
 > in MIP6.
 > 
 > >> >  > Anything that talks about NAT traveral
 > >> >> without keepalives is not useful. 
 > >> > 
 > >> > that was an oversight. will fix this.
 > >> 
 > >> Mph.  There is quite a bit more to say about NAT traversal.
 > >> That the current wakikawa draft is under-specifying this is
 > >> putting it mildly ,:-)
 > > 
 > > Your updates would be always appreciated. 
 > 
 > We covered a lot of area in RFC 3519.  You could start by
 > checking off the issues covered there, and how they are to be
 > handled.
 > 
 > For MIP6 there is the additional issue of how to handle various
 > types of NAT when you're doing route optimization - many of those
 > are the same as those covered quite well in
 > draft-huitema-v6ops-teredo-04.txt .
 > 
 > I expect NAT traversal to be important for MIP6 over IPv4, but I
 > don't expect it to be trivial.
 > 
 > 	Henrik
 > 
 >

---

From: [email-masked]
Date: Mon, 4 Apr 2005 09:39:46 -0700

> So, what do you mean by "MN establishes SA for IPv4 adresses"?

the SPD entries will have v4 addresses as tunnel end points.

from section 5.2.1 of draft-wakikawa

  Mobile Router SPD OUT

     - IF source = mr_hoa & destination = ha_ipv6
          & proto = mh & mhtype = BU
       Then use SA ESP Tunnel mode
                      outer src addr = mr_ipv4_coA
                      outer dst addr = ha_ipv4

Vijay

---

From: [email-masked]
Date: Wed, 6 Apr 2005 10:25:05 -0700

Alex,

there are multiple ways of doing this. thats why I havent
mentioned how we will fix this. infact, the WG can decide
on this. we will get to that later.

infact, if UDP encapsulation of IPsec packets is used as
described in RFC 3948, (see section 9 of draft-wakikawa),
we *don't* need to specifiy anything. RFC 3948 already
specifies a NAT keepalive mechanism

somebody mentioned dummy ICMP messages. others mentioned
sending binding updates now and then. both should work.

Vijay

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> ext Alexandru Petrescu
> Sent: Wednesday, April 06, 2005 4:41 AM
> To: Vijay Devarapalli
> Cc: Soliman, Hesham; [email-masked]
> Subject: Re: [Mip6] draft-soliman and draft-wakikawa
> 
> 
> Vijay Devarapalli wrote:
> >> Anything that talks about NAT traveral without keepalives is not
> >> useful.
> > 
> Yes, but how?  When you say "will fix this" and give no detail or 
> potential idea about how this could be done, it sounds like 
> you already 
> know how to do it and not care very much about the scoping or 
> requirements (that don't yet exist anyways).  I may be wrong with my 
> interpretation of "will fix this" - sorry - but that's what 
> it sounds to 
> me at this second affirmation.
> 
> Alex
> 
>