Subject: [Mip6] new DSMIP draft

From: "Hesham Soliman" <[email-masked]>
Date: Mon, 9 Jul 2007 23:37:22 +1000

Folks, 

Until the draft is announced you can find it here:
http://www.elevatemobile.com/ietf/draft-ietf-mip6-nemo-v4traversal-05.txt

There are some id nits that I plan to handle with WGLC, I'm transferring it
to xml now. 

Hesham

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

---

From: <[email-masked]>
Date: Tue, 10 Jul 2007 12:21:27 +0200

Hi Hesham,

A few comments:

To me, there is some confusion in the draft as to whether 
RH type 2 and HAO DST-OPT are used when MIPv6 signaling messages
are encapsulated in IPv4.

I think, that you now want to say that these are not used (?)
Therefore the HAO DST-OPT have disappeared from Packet format A. in
Section 4.2 - 
Right ?

If so, the RH type 2 should also disappear from Packet Format B, same
section (?)

For clarity I think that it could be good to add a few lines somewhere
emphasizing this general difference to [MIPv6]. I.e., not only are we
encapsulating
in IPv4, RH and DST-OPT have also disappeared. 

A long the same lines, I think that the last part of section 2.3.2.1
needs 
updating, Ipv4-mapped addresses are no longer used - right ?

Finally, Section 2.2 on Mobile Prefix Solicitations and Advertisements
doesn't say 
whether these messages are sent with DST-OPT and RH. Such is a MUST in
[MIPv6] and therefore
it would be good to clarify whether we keep them here or not.

Also in Section 2.2., I do not understand the reference:   

   "Securing such messages would require the mobile node to have
security
   association with the home agent, using IPsec (AH or ESP) and based on
   the mobile node's IPv4 care-of address as described in [MIPv6]."

- ??

It is also here said that

   "If this effect
   is not desired, the mobile node can base the SA on the information in
   the inner header (i.e. using the home agent's IPv6 address, the
   mobile node's home address and the ICMP protocol number). Such
   security association would use transport mode ESP protection."

Why should this be ESP transport, do you want to say IPv4, IPv6, ESP,
ICMP - as in [MIPv6]
had we no RH/DST-OPT, and specifically NOT:

Ipv4, ESP, IPv6, ICMP.

Thanks,
Karen

> -----Original Message-----
> From: Hesham Soliman [mailto:[email-masked]] 
> Sent: Monday, July 09, 2007 3:37 PM
> To: [email-masked]; [email-masked]
> Subject: [Mip6] new DSMIP draft
> 
> Folks, 
> 
> There are some id nits that I plan to handle with WGLC, I'm 
> transferring it to xml now. 
> 
> Hesham
> 
> 
>

---

From: "Hesham Soliman" <[email-masked]>
Date: Tue, 10 Jul 2007 21:38:47 +1000

Hi Karen,

 > Therefore the HAO DST-OPT have disappeared from Packet format A. in

=> Well, since we're forced to use the HoA in the src address field, the HAO
becomes redundant, so yes, that's true.

 > If so, the RH type 2 should also disappear from Packet Format B, same

=> Yes, it's a slip in the text.

 > in IPv4, RH and DST-OPT have also disappeared. 

=> ok.

 > updating, Ipv4-mapped addresses are no longer used - right ?

=> I thought I did that, hmm, I'll take a look.

 > it would be good to clarify whether we keep them here or not.

=> Yes.

 >    the mobile node's IPv4 care-of address as described in [MIPv6]."

=> This particular text is about 3 years old. At the time, I think my
intention was to highlight that if the MN is in an IPv4 network and strictly
follows the security requirements for those messages, which may be exchanged
before the MN discovers its home address, then the IPv4 HoA may have to be
used. That might be tricky with IPv4 and especially when NATs are present. 

 > had we no RH/DST-OPT, 

=> Right.

 > Ipv4, ESP, IPv6, ICMP.

=> Well, this format won't work if a NAT is present. Or do you mean
IPv4/UDP/ESP/...etc? 

Hesham

---

From: <[email-masked]>
Date: Wed, 11 Jul 2007 09:38:02 +0200

Hi,'

> > RH type 2 and HAO DST-OPT are used when MIPv6 signaling 
> messages  > are encapsulated in IPv4.
>  >
>  > I think, that you now want to say that these are not used 
> (?)  > Therefore the HAO DST-OPT have disappeared from Packet 
> format A. in  > Section 4.2 -  > Right ?
> 
> => Well, since we're forced to use the HoA in the src address 
> field, the HAO becomes redundant, so yes, that's true.
> 

"forced to use" - because we should not have ipv4 mapped addresses on
the wire - ?

<snip>

>  > Why should this be ESP transport, do you want to say IPv4, 
> IPv6, ESP,  > ICMP - as in [MIPv6]  > had we no RH/DST-OPT, 
> 
> => Right.
> 
>    and specifically NOT:
>  >
>  > Ipv4, ESP, IPv6, ICMP.
> 
> => Well, this format won't work if a NAT is present. Or do 
> you mean IPv4/UDP/ESP/...etc? 

If there is a NAT in the path, IP ESP IP changes to (should be changed
to)
IP UDP ESP IP, RFC 3948.

In [MIPv6] these messages - Mobile Prefix Advertisements - are sent with
RH and DST-OPT and 
thus protected with IPSec ESP transport.

Now, if (?) we are eliminating the RH and DST-OPT also here, which makes
sense if they are eliminated
everywhere else, then, as for the BU/BACK, we have the choices of
* ESP transport on inner IPv6 level - adding Ipv4/IPv4 UDP tunnel
headers afterwards.
* ESP tunnel (with or without UDP) anchored on inner packet selectors.
to protect this communication.

Please note, that I do not want to reopen the IPSec-tunnel headers and
more discussion. I am simply saying that
the Mobile Prefix Advertisment situation is similar to the BU/BACK
discussion.
(Yes, except that NAT discovery shouldn't be needed.)

Karen

---

From: "Premec, Domagoj" <[email-masked]>
Date: Wed, 25 Jul 2007 16:36:32 +0200

Hi Hesham,

The draft is inconsistent about the situation when the HA doesn't support the IPv4 HoA. In section 2.3.1, 4th paragraph, the draft requires the MN not to send (SHOULD NOT) IPv4 HoA option in future binding updates. In section 4.4, 1st bullet on page 19, the draft states the MN MAY include IPv4 HoA option in future binding updates. I would prefer the "SHOULD NOT" behaviour.

thanks
domagoj

> Sent: 09. srpanj 2007 15:37

---

From: "Hesham Soliman" <[email-masked]>
Date: Thu, 26 Jul 2007 01:58:18 +1000

Hi Domagoj, 

Thanks for the catch. I agree with you. I'll add this to the LC comments
when we start receiving them. 

Hesham 

 > From: Premec, Domagoj [mailto:[email-masked]] 
 > Sent: Thursday, July 26, 2007 12:37 AM
 > To: Hesham Soliman
 > Cc: [email-masked]
 > Subject: RE: [Mip6] new DSMIP draft
 > 
 > Hi Hesham,
 > 
 > The draft is inconsistent about the situation when the HA 
 > doesn't support the IPv4 HoA. In section 2.3.1, 4th 
 > paragraph, the draft requires the MN not to send (SHOULD 
 > NOT) IPv4 HoA option in future binding updates. In section 
 > 4.4, 1st bullet on page 19, the draft states the MN MAY 
 > include IPv4 HoA option in future binding updates. I would 
 > prefer the "SHOULD NOT" behaviour.
 > 
 > thanks
 > domagoj
 > 
 >