Subject: review of draft-sarikaya-v6ops-prefix-delegation-01

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sun, 25 Jul 2010 12:56:12 -0500

Bechet and Frank,

The first question is:

Has any cellular standards body mandated DHCPv6 yet?  If yes, why is
that standards body not working on such a document and then sending
their doc in a summary as a liaison to the IETF v6ops?  If not, then I
recommend that a cellular network standards body work on such a
specification and then the IETF can be kept in the loop.

Comments on Abstract:  

Since one has RFC 3633, quite a bit of text in this document can be
covered by this RFC.  The mention of "DHCPV6 servers" is termed as
delegating router as per RFC 3633 and this RFC abstracts the DHCPv6
server term to a delegating router.  This document should do the same.

Comments on Section 1: Introduction:

4th paragraph :  MN is used as a term without defining it first.  Figure
one describes a UE.   Does MN have more than one air interface and does
this document support multiple air interfaces?

6th paragraph: Wrt to "When the MN becomes idle", how long is an idle
period?  What document describes the idle timeout and is there any
keep-alive during idle time?  Such timeouts have impact on the proposals
made by this document.  Why repeat text like "When an operator wants to
renumber..." when once can just reference RFC 4861 and other renumbering
RFC's.

7th paragraph:  A smart phone is being called a fixed node?  Hmm, how it
that?  Doesn't my iPhone move in the wireless LAN domains or when I take
the phone from the U.S. to Europe?  What part of the iPhone is fixed?  I
think you mean the PD but the document does not bring out such a fact
clearly.   It would be good to clarify such facts.  Which IETF document
defines the term of "Machine-to-Machine apps"?  Figure 1 has no block
showing an edge router.   Since the fixed device is not properly
explained , it is not clear what addressing or prefix delegation is
required for it.

Comments on Section 3: 

Section is confusing as to what all nodes entail a DHCP client. 

Comments on Figure 2:

(a)    Figure 1 uses the term of UE while this Figure has switched to
MN.  Both figures should use the same term.  

(b)   It would be good to show DHCPv6 messages between the MN and the AR
since you show relayed message from the AR to the DHCP server.   

(c)    What does your document have to say if DHCPv6 fails?  When will
the MN time out?

(d)   I would just recommend RAPID-COMMIT for cellular networks and
dispense with the 4-way DHCPv6.

(e)   Why is the RA needed?  If the MN has a DHCPv6 client that requests
an IA_PD, why can't the prefix be uses directly by the MN after DHCPv6
is complete?  You also seem to have it backwards.  A host initiates
DHCPv6 on receiving an RA with the M-bit set, so how is this host
initiating DHCPv6 and then the host sees an RA after completion of
DHCPv6 for a prefix?

Comments on Section 3.1: 

(a)    Text like bullet 8 can be removed - why repeat RFC 4862?

(b)   Bullet 9: where is "virtual link" defined?

Comments on Section 3.2:

First sentence: Is it "established for the MN" or  "established by the
MN"? Sentence has to explain more what connection is being established
and between which two entities.

Second paragraph: I don't understand why the Option 82 MUST contain MN's
prefix?  

Comments on Section 3.5

First paragraph can be replaced by a reference to the IETF IPv6 CE
Router specification -
http://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-cpe-router

Second paragraph.  Define "Variant" since "V" is capitalized,  define
"Flexible" since "F" is capitalized.   

Section 3.5.1, second paragraph uses a "reply message containing the
prefix(es)".  Where is this reply message defined?  Section 3.5.2 mostly
repeats section 3.5.1.  What extra messaging takes place and where is
that message defined if, say, 2 prefixes are doled out and each prefix
has a different Lifetime?  Your document has to address such issues.

Comments on Section 3.6

This whole document can dispense with IAID.  Why not use the mac-address
of the MN and send the mac-addr in DHCPv6 relay agent option to the
server?  There is DHCPv6 client-id option that may be used as well.  So
why is the IAID needed?

Further, since you maintain a table, what if a prefix is inadvertently
lost from the AR?  How does the AR recover such an entry from its prefix
table?  

 Comments on Section 4:

This section is full of "MAY" which is not a good way to define any
basic mechanism for use.  Hence this section is really incomplete.

In summary, this document is incomplete at this statge and I'd rather
see a larger cellular wireless standards body work out IPv6, especially
DHCPv6.  Such a body may then provide a summary to the IETF.

Hemant

 

 

 

Hemant Singh
Technical Leader.engineering
Product Development
[email-masked]
Phone: +1 978 936 1622
Cisco Systems, Inc.
United States
Cisco.com - http://www.cisco.com

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html