Subject: Re: [MEXT] FW: Summary for the changes in hiopt-13

From: Heejin Jang <[email-masked]>
Date: Wed, 16 Apr 2008 09:49:21 +0000 (GMT)

Hi, Jari. 

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]] 
> Sent: Wednesday, April 16, 2008 5:22 PM
> To: [email-masked]
> Cc: Premec, Domagoj; [email-masked]
> Subject: Re: [MEXT] FW: Summary for the changes in hiopt-13
> 
> Heejin,
> 
> >> This is actually a problem in -13 (I reviewed it myself 
> after sending 
> >> out the mail this morning).
> >>
> >> I think we need to be able to indicate (a) FQDNs, (b) IPv6 
> addresses, 
> >> or
> >> (c) IPv4 addresses. DNS is quite capable of resolving an FQDN to 
> >> either
> >> IPv4 or IPv6 addresses or both... no flags needed.
> >>     
> >
> > Ok.  for FQDN sub-opt-code, I'll fallback to the previous 
> version. (v12).
> >  
> >   
> >> And I think this draft should only focus on Mobile IPv6. 
> We get the 
> >> Mobile IPv6 home agent's addresses (be it v4 or v6), not something 
> >> else...
> >>     
> >
> > " focus on Mobile IPv6..not something else..." means there 
> is no need 
> > to add what Premec suggested, that is IPv4 HoA, IPv4 subnet?
> >   
> 
> The IPv6 network prefix is there presumably because we want 
> to enable the use of the HA anycast address. There is nothing 
> corresponding in IPv4, so we don't need a prefix. And this 
> draft does not give us IPv6 home addresses, so there is no 
> need for IPv4 home addresses either.

As far as I know, there is a dynamic discovery in MIPv4, too. 
Section 3.6.1.2. of draft-ietf-mip4-rfc3344bis-06.txt described about that
procedures (page 47, last paragraph).

But these new options do not aim at allowing access to MIPv4 as you told, 
IPv4 HoA and IPv4 subnet won't be included in a new version.

> 
> > For clarity, then I'll revise as below. (Your previous mail 
> was also 
> > considered.)
> >
> > OLD: 
> >        Sub-opt-code
> >
> >                0    Reserved
> >                1    Home network identifier (only admitted
> >                      in a Home Network Information option)
> >                2    IPv6 home network prefix
> >                3    IPv6 home agent address
> >                4    IPv4 address of the dual-stacked home agent
> >                5    Home agent FQDN
> >                6 .. (2^16-1) Reserved
> > NEW:
> >                0    Reserved
> >                1    Home network identifier (only admitted
> >                      in a Home Network Information option)
> >                2    IPv6 home network prefix
> >                3    IPv6 home agent address
> >                4    Home agent FQDN
> >                5 .. (2^16-1) Reserved
> >   
> 
> No, this is wrong. You *do* need to have IPv4 address of the 
> Mobile IPv6 home agent as well. Don't change this part, just 
> change the parts where you talked about Mobile IPv4... these 
> options will give you access to the Mobile IPv6 service, be 
> it over IPv4, IPv6 or whatever. But these options do not give 
> you access to Mobile IPv4 service.

I see. Ok.

> > /* Node that the below is for IPv6 address sub-opt-code, 
> not for FQDN 
> > sub-opt-code*/
> >
> > When the Sub-opt-code is set to 3, the Home Network Parameter field 
> > MUST consist of a Flags octet followed by the 128-bit IPv6 
> address of 
> > the home agent.  The most significant bit of the Flags 
> octet encodes a 
> > DSMIP field, and the seven remaining bits are Reserved 
> (must be set to 
> > 0 and ignored on receipt).  A Value of 1 in the DSMIP field 
> indicates 
> > that the home agent specified by the following IPv6 address has an 
> > IPv4 address and has a capability to support DSMIPv6 [DSMIPv6]. A 
> > value of 0 means that the home agent only supports Mobile IPv6.
> >   
> 
> I don't see a need for this. You will deliver one or several 
> of: IPv4 address, IPv6 address, IPv6 prefix, FQDN. Depending 
> on what you get and how the FQDN is resolved, you will either 
> have or not have IPv4 addresses in your final set. If you do, 
> that means that server should be contactable by IPv4 using 
> DSMIP. No flag needed.

Ok. I'll keep using the previous one. 

Thanks again. :)

- Best regards, 
Heejin

> Jari
_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: Heejin Jang <[email-masked]>
Date: Wed, 16 Apr 2008 10:15:24 +0000 (GMT)

Some prefixes allocated for IPv6 autoconfiguration may not 
be available for DHAAD. So the current sub-opt-code 1 (both for auto-conf 
and DHAAD) is not exact in that sense. Now if we narrow down the use of 
the provided  prefix for only DHAAD, I need to mention it in the document.
 
Agree?

------- Original Message -------
Sender : Heejin Jang<[email-masked]> R&D Staff Member/Communication & Networking Lab/Samsung Advanced Institute of Technology
Date   : 2008-04-16 19:04 (GMT+09:00)
Title  : Re: Re: [MEXT] FW: Summary for the changes in hiopt-13

See below. 

> Sent: Wednesday, April 16, 2008 6:50 PM
> To: Premec, Domagoj
> Cc: [email-masked]; [email-masked]
> > In deployments where the per-MN prefix model is used, 
> letting the MN know the home prefix is equal to assigning the 
> address to the MN. I&#39;m not clear if DHAAD works with per-MN 
> prefix model. I thought that the main purpose of the home 
> network prefix is the same as the MIP6_HOME_PREFIX attribute 
> from RFC 5026. For DHAAD, the better way might be to include 
> prefix length in the Home agent address option, and if the 
> bits after the prefix length are zero, the MN should run 
> DHAAD. In this way the MN could be told to run DHAAD with one 
> prefix and use another prefix for its home address configuration. 
> >   
> 
> Clearly we had different ideas about the use of the prefix in 
> hiopt. But I think it is intended for the use of DHAAD. See 
> paragraph 1 in Section 1.

As shown in Fig in page 10 of v13, the sub-option with sub-opt-code 1 
carries home network prefix together with valid & preferred lifetimes.
This means that the prefix also will be used for IPv6 address autoconfiguration.
I meant that the provided prefix was both for DHAAD and for Autoconf.

If the provided prefix is intended only for the use of DHAAD and 
the auto-configuration is not allowed with it, it should be mentioned clearly
in the document..isn&#39;t it?

> I don&#39;t think this draft should be extended to deal with the 
> home address configuration (be it per-mn prefix or individual 
> addresses).
> 
> Jari
>