Re: [Mipshop] Comments on draft-ietf-mipshop-pfmipv6-05.txt

[Hidetoshi Yokota <[e-mail]>]

Hi Vijay,

Attached please find the further updated version (I'll submit it by the
deadline).

Vijay Devarapalli wrote:
> Hidetoshi Yokota wrote:
> 
>>>>  >>    The encapsulation type for these user packets SHOULD follow 
>>>> that used
>>>>  >>    in the tunnel between the LMA and MAG (e.g., IPv6-in-IPv6 
>>>> [RFC5213]
>>>>  >>    or GRE [GREKEY]).
>>>>  >
>>>>  > I guess you need to mention UDP encapsulation too, in case an UDP 
>>>> tunnel
>>>>  > is setup between the PMAG and the NMAG.
>>>>
>>>> The above paragraph was revised as follows:
>>>>
>>>>    The encapsulation type for these user packets SHOULD follow that 
>>>> used
>>>>    in the tunnel between the LMA and MAG (IPv6-in-IPv6, IPv6-in-IPv4,
>>>>    IPv6-in-IPv4-UDP, IPv6-in-IPv4-UDP-TLV as specified in [RFC5213], 
>>>> GRE
>>>>    as specified in [GREKEY] or any new method defined in the future).
>>> Ok, but TLV is specified in [GREKEY], not in RFC 5213.
>>
>> You mean "draft-ietf-netlmm-pmip6-ipv4-support-13.txt" [IPv4PMIPv6]? The
>> references are modified as such.
> 
> No, the TLV header and the encapsulation with the TLV header is defined 
> in draft-ietf-netlmm-grekey-option-09.txt. 
> draft-ietf-netlmm-pmip6-ipv4-support just refers to the GRE key draft 
> for the TLV encapsulation.

Now I see what you mean. How about the following text:

   The encapsulation type for these user packets SHOULD follow that used
   in the tunnel between the LMA and MAG (IPv6-in-IPv6 as specified in
   [RFC2473], IPv6-in-IPv4, IPv6-in-IPv4-UDP as specified in
   [IPv4PMIPv6], TLV-header UDP tunneling as specified in [GREKEY] or
   any new method defined in the future).

>>>>  >> 6.2.3.  IPv4 Address Option
>>>>  >>
>>>>  >>    As described in Section 4.3, if the MN is IPv4-only mode or 
>>>> dual-
>>>>  >>    stack mode, the MN requires IPv4 home address (IPv4-MN-HoA).  
>>>> This
>>>>  >>    option has alignment requirement of 4n.
>>>>  >>
>>>>  >>       0                   1                   2                   3
>>>>  >>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 
>>>> 9 0 1
>>>>  >>      
>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>  >>      | Option-Type   | Option-Length |  Option-Code  |    
>>>> Reserved   |
>>>>  >>      
>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>  >>      |                      IPv4 
>>>> Address                             |
>>>>  >>      
>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>  >>
>>>>  >>    Option-Type    TBD3
>>>>  >>
>>>>  >>    Option-Length  6
>>>>  >>
>>>>  >>    Option-Code
>>>>  >>
>>>>  >>                   0  Reserved
>>>>  >>
>>>>  >>                   1  IPv4-MN-HoA
>>>>  >
>>>>  > It looks like you don't need a "Option-Code" field here. This 
>>>> options
>>>>  > seems to be only for carrying the MN's IPv4 address. There is no 
>>>> other use.
>>>>  >
>>>>  > BTW, can't we re-use the IPv4 Home Address Option that we already 
>>>> have?
>>>>  > See section 3.1.1 of RFC 5555.
>>>>
>>>> Thanks for your input. We should reuse this option. Section 6.2.3 was
>>>> moved to 6.2.7 without defining a new option. Section 8 (IANA
>>>> Considerations) was revised accordingly.
>>> On second thoughts lets not re-use the IPv4 Home Address Option from RFC
>>> 5555. I heard from Sri, that we might have to define a new option for
>>> carrying the IPv4 address of the mobile node in
>>> draft-ietf-netlmm-pmip6-ipv4-support-13.txt. I think we should that 
>>> option.
>>
>> It seems that -13.txt hasn't had that option, yet, but our latest
>> document refers to it hoping that the above reference will be defined in
>> the future...
> 
> Version 14 will have the new option for the IPv4 home address.

That is captured in the latest version. Please check Section 6.2.7 if it
is acceptable.

Regards,
-- 
Hidetoshi

> Vijay
> 
> 
>