Subject: [MEXT] draft-xia-mext-hioptv4-01 and draft-ietf-mip6-hiopt-17 comments

From: Tomasz Mrugalski <[email-masked]>
Date: Thu, 17 Mar 2011 22:57:51 +0100

Dear MEXT WG,
Behcet asked me to review draft-xia-mext-hioptv4-01.txt. It refers to
draft-ietf-mip6-hiopt-17.txt, so I'd like to briefly comment on both of
them.

Disclaimer: I'm not involved in MEXT activity (nor do I intend to). I'm
quite familiar with DHCPv6 and to some extent DHCPv4 protocols, so my
comments are related to those aspects.

draft-ietf-mip6-hiopt-17:
MIP6 Relay Agent Option defined in Section 3.2 of
draft-ietf-mip6-hiopt-17 is specific to one option only. On the other
hand Ted's RSOO proposal is generic and can be applied to any options.
This make RSOO better approach. I strongly suggest to modify Section 3.2
of draft-ietf-mip6-hiopt-17 to reference RSOO draft, rather than define
its own dedicated option.

draft-xia-mext-hioptv4-01:
In Section 1 you enumerate all IPv4-IPv6 permutations, without any
justification why they are actually needed. What's the use case there?
My understanding is that there is Dual Stack mobile node. Is it supposed
to do DHCPv4 only? Why? If client visits network that is IPv4 only, how
is it supposed to do MIPv6?

If you have dual stack mobile node, it should run both DHCPv4 and DHCPv6
clients, each configuring its own protocol family.

I think Ted's major objection was Section 4.2, where DSMIPv6 Relay
Agent Option is defined. Why do you need this option for? What options
is it supposed to carry? Are you expecting it to convey DHCPv6 options,
as defined in mip6-hiopt-17? That would be wrong on many levels. You
would encapsulate DHCPv6 suboptions into DHCPv4 options. DHCPv4 clients
typically don't have parsing capabilities of DHCPv6 option formats.

At current form, this draft is unclear at best. Who is including
OPTION_DSMIP6_RELAY option? Relay?

My generic recommendation is that authors should should start with:
- explaining why you need this instead of using DHCPv4 for IPv4
  configuration and DHCPv6 for IPv6 configuration.
- redesigning those option to not requiring conveying DHCPv6 options in
  DHCPv4.
- explain your use case and the rationale behind it.

References:
RSOO draft:
http://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-relay-supplied-options/

Please keep me on cc: as I'm not subscribed to mext mailing list.

-- 
Tomek

---

From: xiayangsong <[email-masked]>
Date: Thu, 17 Mar 2011 23:13:26 +0000

Hi Tomek

Thank you for reviewing the document.

Please see my inline comments...

BR
Frank

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tomasz Mrugalski
Sent: Thursday, March 17, 2011 2:58 PM
To: MEXT WG
Cc: Behcet Sarikaya
Subject: [MEXT] draft-xia-mext-hioptv4-01 and draft-ietf-mip6-hiopt-17 comments

Dear MEXT WG,

draft-xia-mext-hioptv4-01:
In Section 1 you enumerate all IPv4-IPv6 permutations, without any
justification why they are actually needed. What's the use case there?
My understanding is that there is Dual Stack mobile node. Is it supposed
to do DHCPv4 only? Why? If client visits network that is IPv4 only, how
is it supposed to do MIPv6?
Frank=>This is all about Dual Stack MIPv6.  There is one scenario that a IPv4 only mobile node needs to discover a home agent address through DHCPv4 protocol.
According to specification of DSMIPv6, the home address needs both an IPv4
and IPv6 address.

If you have dual stack mobile node, it should run both DHCPv4 and DHCPv6
clients, each configuring its own protocol family.
Frank=>DSMIPv6 mobile node does not necessarily support both IPv4 and IPv6,
or DHCPv4 and DHCPv6.

I think Ted's major objection was Section 4.2, where DSMIPv6 Relay
Agent Option is defined. Why do you need this option for? What options
is it supposed to carry? Are you expecting it to convey DHCPv6 options,
as defined in mip6-hiopt-17? That would be wrong on many levels. You
would encapsulate DHCPv6 suboptions into DHCPv4 options. DHCPv4 clients
typically don't have parsing capabilities of DHCPv6 option formats.
Frank=>Just I explained aforementioned, we need define DHCPv4 option for
carrying home agents information(such as IPv6 addresses). We can't encapsulate
DHCPv6 suboptions into DHCPv4 options because the client is DHCPv4 only.

At current form, this draft is unclear at best. Who is including
OPTION_DSMIP6_RELAY option? Relay?
Frank=>Access routers as DHCP relay and DHCPv4 servers includes the option.

Frank=>Thank your recommendation,  and we will update this draft accordingly.

References:
RSOO draft:

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

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 18 Mar 2011 13:48:10 -0700 (PDT)

Hi Tomek,
  Can you please confirm that 

RSOO defined in draft-ietf-dhc-dhcpv6-relay-supplied-options-04 is for
DHCPv6 only. There's no need or intent to define similar option
for DHCPv4.

i.e. draft-xia-mext-hioptv4-01  has no RSOO problem as in 
draft-ietf-mip6-hiopt-17?

Thanks,

Behcet

---

From: Tomasz Mrugalski <[email-masked]>
Date: Sat, 19 Mar 2011 17:40:24 +0100

> DHCPv6 suboptions into DHCPv4 options because the client is DHCPv4 only.
Agree. I maybe didn't express myself clearly. DHCPv6 options must not be
encapsulated in DHCPv4 options.

Maybe I misunderstood the intent of the authors, so let me explain how I
read the draft: draft-xia-mext-hioptv4-01, section 4.2 defines DSMIPv6
Relay Agent Option (a DHCPv4 Option) that contains sub-options field.
Its content is defined as "A series of sub-options as specified in
I-D.ietf-mip6-hiopt". ietf-mip6-hiopt-17 defines couple DHCPv6 options.
I'm not sure how can this be interpreted otherwise than an attempt to
encapsulate DHCPv6 suboptions within DHCPv4 option.

> Frank=>Access routers as DHCP relay and DHCPv4 servers includes the option.
I think this should be clarified in the draft.

Hope that helps,
Tomek

---

From: Tomasz Mrugalski <[email-masked]>
Date: Sat, 19 Mar 2011 17:47:14 +0100

On 2011-03-18 21:48, Behcet Sarikaya wrote:
> DHCPv6 only. 
Yes. I confirm.

> There's no need or intent to define similar option
> for DHCPv4.
I can't speak for the whole DHC WG. I haven't heard about such plans.
Also, keep in mind that DHCPv4 uses completely different approach to
relaying as compared to DHCPv6, so the usefulness of defining RSOO for
DHCPv4 is somewhat questionable.

Tomek

---

From: xiayangsong <[email-masked]>
Date: Mon, 21 Mar 2011 17:16:54 +0000

Hi Tomek

Thank your response. 
Please check my comments inline.

BR
Frank

-----Original Message-----
From: Tomasz Mrugalski [mailto:[email-masked]] 
Sent: Saturday, March 19, 2011 9:40 AM
To: xiayangsong
Cc: MEXT WG; Behcet Sarikaya
Subject: Re: [MEXT] draft-xia-mext-hioptv4-01 and draft-ietf-mip6-hiopt-17 comments

Frank=>Agree.

Maybe I misunderstood the intent of the authors, so let me explain how I
read the draft: draft-xia-mext-hioptv4-01, section 4.2 defines DSMIPv6
Relay Agent Option (a DHCPv4 Option) that contains sub-options field.
Its content is defined as "A series of sub-options as specified in
I-D.ietf-mip6-hiopt". ietf-mip6-hiopt-17 defines couple DHCPv6 options.
I'm not sure how can this be interpreted otherwise than an attempt to
encapsulate DHCPv6 suboptions within DHCPv4 option.
Frank=>Sorry for the confusion we introduced. Actually, we related our
draft to ietf-mip6-hiopt-17 just because they have similar scenarios.
Our draft was supposed to define an independent set of DHCPv4 options.

Frank=>We will add this.

Hope that helps,
Tomek