|
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
|