Subject: [nemo] Re: [Mip6] draft-soliman and draft-wakikawa

From: Ryuji Wakikawa <[email-masked]>
Date: Mon, 04 Apr 2005 13:27:29 +0900

Hesham and Vijay

Here is the history.
draft-heshams does not support NAT traversal, and I don't see any
solution to solve NAT traversal by using mapped address.
We will design an extension using mobility option to solve NAT issue
and throw away MIPv4 support which is not our goal in the draft.

ryuji

At Fri, 1 Apr 2005 19:43:55 -0500,
Soliman, Hesham wrote:
> 
> 
>  > > I've expressed my opinion on the genreal issue before.
>  > > Regarding this topic of comparison, I don't think the 
>  > > difference you expressed is worth writing new drafts
>  > > about. It would be much easier if you just suggest this to
>  > > us and we would discuss it. Instead, now we end up with
>  > > discussing very similar drafts for no apparent reason, which
>  > > takes more cycles.
>  > > I respect your right to write a new draft about whatever you
>  > > want. But for such a small differemce, you were welcome to
>  > > send a comment and discuss it...
>  > 
>  > I was saying the opposite. show me something of value from
>  > draft-soliman that is not there in draft-wakikawa and we will
>  > take it up from there.. :)
> 
> => This is funny indeed, worth the smile :). So a draft comes 
> out call it draft A, then draft B comes out much later and the 
> argument for having draft B is that it contains everything in
> draft A.... No I won't start from this assumption of course.
> FWIW, I already mentioned that draft-soliman supports other
> scenarios.
> 
> Hesham
> 
>  > 
>  > > FWIW I prefer not introducing a new option, the current
>  > > approach in draft-soliman fits easily within an implementation
>  > > as Conny already explained. 
>  > 
>  > FWIW, we have implementations of draft-wakikawa too...
>  > 
>  > > Anyway, this is a secondary issue
>  > > and something that can be fine tuned much later in the process.
>  > 
>  > I agree.
>  > 
>  > Vijay
>  > 
>  > > 
>  > > Hesham
>  > > 
>  > > 
>  > >  > -----Original Message-----
>  > >  > From: [email-masked] [mailto:[email-masked]]On 
>  > >  > Behalf Of
>  > >  > Vijay Devarapalli
>  > >  > Sent: Friday, April 01, 2005 6:36 PM
>  > >  > To: [email-masked]
>  > >  > Subject: [Mip6] draft-soliman and draft-wakikawa
>  > >  > 
>  > >  > 
>  > >  > 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.
>  > >  > 
>  > >  > Vijay
>  > >  > 
>  > >  > _______________________________________________
>  > >  > Mip6 mailing list
>  > >  > [email-masked]
>  > >  > https://www1.ietf.org/mailman/listinfo/mip6
>  > >  > 
>  > > 
>  > > ===========================================================
>  > > 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: Alexandru Petrescu <[email-masked]>
Date: Wed, 06 Apr 2005 13:55:27 +0200

> and throw away MIPv4 support which is not our goal in the draft.

Ryuji, how are you going to design this extension with a mobility
option?  I know of a NAT that blocks all IP-in-IP and as long as the
mobility option is deep below IP it's going to be of no use.

MIP4 has a nice feature for NAT traversal, that I know implemented. 
That feature could be re-used.  I don't understand why you would throw 
it away and design a new option in the mobility header?

Alex

---

From: Ryuji Wakikawa <[email-masked]>
Date: Mon, 11 Apr 2005 04:34:55 +0900

Alex and Hesham

At Wed, 06 Apr 2005 13:55:27 +0200,
> it away and design a new option in the mobility header?

I was not so clear on my last sentence.  I mean we don't have any
intention to use v4 HoA for v4 mobility on MIPv6 in our draft.  Not
talking about MIPv4's NAT traversal mechanism. 
Since MIP6 has different signaling way, we cannot simply re-use the
MIPv4 mechanism to MIPv6. However, there are serveral points which we
can re-use.

ryuji