Subject: RE: [Mip4] Working Group Last call for draft-ietf-mip4-dsmipv4-02.txt

From: "Tsirtsis, George" <[email-masked]>
Date: Wed, 25 Jul 2007 05:50:36 -0700

Sorry for the delay but here are some additional comments

-----Original Message-----
From: Alexandru Petrescu [mailto:[email-masked]] 
Sent: Wednesday, June 27, 2007 5:18 PM
To: Tsirtsis, George
Cc: [email-masked]
Subject: Re: [Mip4] Working Group Last call for
draft-ietf-mip4-dsmipv4-02.txt

:-)

Tsirtsis, George wrote:
> About implicit mode: 
> Implicit mode, means that MIP signaling is NOT used to indicate the
IPv6
> addresses/prefixes for a given MN. How these address/prefixes are
known
> by the MN and the HA is simply outside the scope of this
specification.
> The MN can use DHCP prefix delegation, or HA and MN could be
> preconfigured with IPv6 prefixes, or some other mechanism that I do
not
> know about may be used. There is nothing we need to say about any of
> this here.

I think what one needs in DSMIPv4 implicit mode is HA to hold a new 
table IPv4 HoA - IPv6 HoA.  I don't think prefix delegation can offer 
that association.

GT> Yes, but my point is that how it does this is entirely an
implementation issue and there is no protocol work that needs to be done
for it.

> About encapsulation methods: 
> When IPv6 is tunneled to the MN's IPv4 HoA, you get IPv6-in-IPv4 i.e.,

For this IPv6-in-IPv4 - which RFC? rfc2529 (6over4 - IPv4 protocol 41)? 
  Shouldn't this be referred to?  You thought another?

GT> I think the obvious choice is RFC4213

> the HA encapsulates packets with destAddr==MN's IPv6 HoA, to an IPv4
> tunnel with destAddr==MN's IPv4 HoA. Then, the IPv4 packets (with
> destAddr==MN's IPv4 HoA) are tunneled to the MN's CoA with whatever
> mechanism is negotiated in MIPv4 messages (IPinIP, Minimal
Encapsulation
> etc). I think this is clear and the DS support does not interfere with
> the different MIPv4 tunnel types.
> If IPv6 is tunneled to the MN's CoA, however, then only
> IPv6-in-IPv4 is used i.e., the HA encapsulates packets with
> destAddr==MN's IPv6 HoA, in an IPv4 tunnel with destAddr==MN's IPv4
CoA.
> In that case the different MIP4 tunnel types are not used for this.
> I could add such clarification in the specification. Would that be
> acceptable to you?

Ok if one refers to rfc2529 (or another you may have thought), thanks.

GT> again RFC4213

Alex

> 
> -----Original Message-----
> From: Alexandru Petrescu [mailto:[email-masked]] 
> Sent: Wednesday, June 27, 2007 4:29 PM
> To: Tsirtsis, George
> Cc: [email-masked]
> Subject: Re: [Mip4] Working Group Last call for
> draft-ietf-mip4-dsmipv4-02.txt
> 
> Tsirtsis, George wrote:
>> Hi Alex,
>>
>> Thanks for the review. I think this is the 2nd or 3rd one you provide
>>  for this draft :-) I think most of the comments this time can be 
>> resolved easily.
> 
> I get your point, but I don't quite understand how you solve the issue

> of GRE, Minimal Encapsulation and IP-in-IP not supporting IPv6.  Or
how 
> you assume HA to learn the IPv6 HoA in implicit mode by means outside 
> this document.
> 
> Alex
> 
> 
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email 
> ______________________________________________________________________
> 

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

-- 
Mip4 mailing list: [email-masked]
    Web interface: https://www1.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 25 Jul 2007 13:28:48 -0500

Tsirtsis, George wrote:
> -----Original Message----- From: Alexandru Petrescu 
> [mailto:[email-masked]] Sent: Wednesday, June 27, 2007 
> 5:18 PM To: Tsirtsis, George Cc: [email-masked] Subject: Re: [Mip4] 
> Working Group Last call for draft-ietf-mip4-dsmipv4-02.txt
> 
> :-)
> 
> Tsirtsis, George wrote:
>> About implicit mode: Implicit mode, means that MIP signaling is NOT
>>  used to indicate the IPv6 addresses/prefixes for a given MN. How
>> these address/prefixes are known by the MN and the HA is simply
>> outside the scope of this specification. The MN can use DHCP prefix
>> delegation, or HA and MN could be preconfigured with IPv6 prefixes,
>> or some other mechanism that I do not know about may be used. There
>> is nothing we need to say about any of this here.
> 
> implementation issue and there is no protocol work that needs to be 
> done for it.

Ok...

>> About encapsulation methods: When IPv6 is tunneled to the MN's IPv4
>>  HoA, you get IPv6-in-IPv4 i.e.,
> 
> For this IPv6-in-IPv4 - which RFC? rfc2529 (6over4 - IPv4 protocol 
> 41)? Shouldn't this be referred to?  You thought another?
> 

Ah I think rfc4213 "Basic Transition Mechanisms for IPv6 Hosts and 
Routers" is appropriate to be referenced in this draft for IPv6-in-IPv4 
encapsulation.  The RFC talks dual-stack and configured tunnelling as 
two different mechanisms.  I think the DSMIP only needs the dual-stack part?

Alex