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

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

More specific response:

 >    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?

=> Correct in the scenario you mentioned. This draft also
supports another scenario: using IPv4 home address and
IPv6 CoA. This is very practical if you want to use 
MIPv6 all the time while having a DS host.

 > 
 > 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).

=> The ToCs are nearly identical with the exception of the 
section talking about NAT traversal. This is actually not
useful in draft wakikawa. Anything that talks about NAT traveral
without keepalives is not useful. draft-soliman intentionally
does not talk about NAT traversal. The idea was that if NAT
traversal is needed it should be used optionally on top. We can
discuss reasons for that if you want.

Hesham

 > 
 > 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: Vijay Devarapalli <[email-masked]>
Date: Fri, 01 Apr 2005 16:41:32 -0800

Soliman, Hesham wrote:
> IPv6 CoA. 

which we are not interested in and out of scope for this
discussion.

 > Anything that talks about NAT traveral
> without keepalives is not useful. 

that was an oversight. will fix this.

Vijay

---

From: Henrik Levkowetz <[email-masked]>
Date: Sun, 03 Apr 2005 15:55:54 +0200

> which we are not interested in and out of scope for this

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.

> 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 ,:-)

	Henrik

---

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

Hi Henrik

At Sun, 03 Apr 2005 15:55:54 +0200,
> out of scope for this discussion.

I individually don't.
Using MIPv4 in IPv6 networks should be discussed in MIPv4 WG.

> That the current wakikawa draft is under-specifying this is

Your updates would be always appreciated. 

ryuji

---

From: Henrik Levkowetz <[email-masked]>
Date: Mon, 04 Apr 2005 08:40:44 +0200

> 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.

However I agree that if this was the case, it wouldn't belong
in MIP6.

> 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: Pekka Savola <[email-masked]>
Date: Mon, 4 Apr 2005 13:55:35 +0300 (EEST)

> draft-huitema-v6ops-teredo-04.txt .

Note that AFAIK, NAT traversal between the bidirectional MN-HA tunnel 
is likely going to be rather simple (if keepalives are considered OK 
in the scenario; as Hesham points out, they might be completely 
unacceptable in some sceanrios [but that's why it could be possible to 
turn them off it there is no NAT on the path]).

NAT traversal for route optimization would be reinventing Teredo 
(i.e., rather complex and definitely not worth the effort), but as far 
as I understand, the authors are not proposing addressing this 
particular thing.

MNs could only use the bidirectional tunnel, and if they wanted to do 
route optimization, they would have to initiate regular transition 
mechanism on the side.

Authors, is this understanding correct?

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Henrik Levkowetz <[email-masked]>
Date: Mon, 04 Apr 2005 13:19:52 +0200

Hi Pekka,

> turn them off it there is no NAT on the path]).

In this case, you'll come pretty close to what's covered in NAT 
traversal for MIPv4 - not complex, but a number of details to 
keep track of.  I think this work should be done.

> as I understand, the authors are not proposing addressing this 

There is no more, or less, "re-inventing" in this case than in
the MN-HA NAT traversal case, and what is required in addition, 
in order to do route optimization is probably not that much more
complex.  I think it would be a pity not to look at this, too;
but I think that the most sensible split between 'worth doing'
and 'not worth doing' might turn out be to solve this for connections
with IPv6 hosts, but not for connections with IPv4 hosts.

> route optimization, they would have to initiate regular transition 

I think it's premature to try to pin down this as the way to go.  
(I also think it could be the wrong way to go).

	Henrik

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 06 Apr 2005 13:40:55 +0200

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

---

From: JinHyeock Choi <[email-masked]>
Date: Fri, 22 Apr 2005 11:57:14 +0900

Dear MIP6 Group

A new WG I-D is announced in DNA WG. 

DNA with unmodified routers: Prefix list based approach
draft-ietf-dna-cpl-00.txt

The current MD (Movement Detection) scheme for MIPv6 is less than 
optimal. When a host moves to an another subnet, if it uses NUD, it 
would take roughly 3 secs to detect a change. Moreover, link-local scope 
of router addresses may cause the host to make a wrong decision.   

This draft describes a fast & robust DNA/MD scheme without a standard 
change, which can be adopted to existing MIPv6 code right now. 

Upon establishing a new link-layer connection, a host checks for link change, 
i.e. determines whether it still remains at the same link or not. 

Currently there is one thing which can represent the identify of a link,

   'The set of all the global and valid prefixes assigned to a link.'

We propose that, at each attached link, the host generates the Complete 
Prefix List, that is, the prefix list contains all the prefixes on the link, 
and when it receives a hint of a a possible link change, (usually link UP
notification from link-layer), it detects the identity of the currently attached
link by consulting the existing prefix list.  

We describe how to generate the Complete Prefix List and to robustly check 
for link change even in the presence of packet losses. 

A URL for this Internet-Draft is:

http://www.ietf.org/internet-drafts/draft-ietf-dna-cpl-00.txt

We are looking forward to your feedback, especially from the people who 
actually implement MIPv6 stack. 

Thanks in advance for your kind consideration. 

Best Regards

JinHyeock Choi and Erik Nordmark 
(Authors)