[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Comments on draft-ietf-ngtrans-isatap-15.txt
Hello folks,
Two factors compelled me to send comments on this list - there is no
official list for discussing ISATAP, and there are enough folks out here
who are interested in ISATAP.
This mail consists of technical comments (some of which, I believe, would
be of interest during deployment of ISATAP), and editorial comments.
If the WG chairs feel that this thread is inappropriate for the list,
they may indicate so. In that case, I would request that replies should
be sent only to me.
Regards,
CP
P.S: This is the third time I am sending this email. Somehow the first
two tries (about 8 hrs ago) have not made it.
Technical comments:
-------------------
1) What is the reason for removal of Section 4.3, draft 14 (Link Layer
Address Option) from the new draft? I can't seem to find any section that
specifies how link-layer address are encoded in ND messages or any
explicit mention that link layer address option should not be used within
the ND messages.
I might be missing something obvious in this one as I have yet to read
RFC2491.
2) Section 4.3 (draft 15). 1st paragraph.
ISATAP interfaces recognize an IPv6 node's required addresses
^^^^^^^^^
What does the word "recognize" imply?
3) Definition of "underlying link" is ambiguous. The phrase "supports
IPv4 (for ISATAP)" has multiple connotations. I have two suggestions.
Replace the term underlying link (the term "underlying" is too generic)
to ISATAP link. In addition, modify the definition to "ISATAP link refers
to the underlying unicast IPv4 network over which IPv6 is tunneled."
4) PRL refresh should be done under three conditions - a) expiry of
PrlRefreshInterval, b) through a manual trigger (out of scope of the
draft), and c) existing routers are determined to be unreachable, and new
routers have to be discovered.
There is no text corresponding to point c). We should add text that says
something like - "If all the routers in the PRL are unreachable, attempts
to refresh the PRL should be made at regular intervals of
PrlNoRtrRefreshInterval ". Since the PrlRefreshInterval is of 1hr,
PrlNoRtrRefreshInterval should have a value much lesser than
PrlRefreshInterval.
5) Section 6.3.4.2. Why is the timer formula
TIMER(i) = MAX((0.5 * MIN_LIFETIME), MinRouterSolicitInterval) and not,
TIMER(i) = MAX((MIN_LIFETIME), MinRouterSolicitInterval) ?
6) Section 7. Second paragraph. I do not understand the line "Sending
implementations map the "All_DHCP_Relay_Agents_and_Servers" multicast
address to a link-layer (IPv4) address by selecting V4ADDR(i) for some
PRL(i)." What is the mechanism for selecting PLR(i)? Random? If so, can
we state that.
It is explicitly mentioned that in an ISATAP site the DHCPv6 server has
to be collocated in all the PRL routers when stateful autoconfiguration
is used. However, no justification is given. My guess is that this
decision was taken because no suitable method for locating DHCPv6 servers
could be agreed upon. Is that correct?
7) The document is built on the premise that mechanisms for Multicast
emulation are not available. Shouldn't there be a section that specifies
ISATAP deployment in networks supporting Multicast emulation?
8) Section 6.2. 1st paragraph.
"Duplicate Address Detection ([RFC2462], section 5.4) is not required"
^^^^^^^^^^^^^
Bit confusing,
in terms of the
level of
requirement. Is
this a MUST NOT,
or a SHOULD NOT.
I think it is
the former.
6. Appendix D. 2nd paragraph
"But, allowing this functionality
prevents ISATAP nodes from perform effective ingress filtering for
IPv6 source addresses in packets they receive. Instead, the nodes
must trust that: 1) site border routers are performing ingress
filtering, and 2) malicious nodes are effectively denied access to
the link."
I am unable to see how the ISATAP routers (node, as per the above
terminology) be hindered from performing ingress filtering. As I
understand, ISATAP hosts will never communicate with non-default routers,
and they will use prefixes advertised only by the ISATAP routers. (Maybe
I am not able to visualize the same network). My network view is
+---+ +-------------+
|Ho-|----------+---------------| PRL router |
|st | | +-------------+
+---+ |
|
|
+-----+-----+
|non-def rtr|
+-----+-----+
____|_______
/ \
| Stub IPv6 |
| n/w |
\____________/
Editorial comments:
-------------------
1) Modify the 2nd sentence in Abstract section (to make it better
sounding) to:
"ISATAP treats the site's IPv4 infrastructure as a NBMA link layer with
no requirement for IPv4 multicast."
2) 2nd Para, Section 1.
This paragraph is supposed to introduce the reader to the main objectives
of the document. With that in mind, the paragraph should be rephrased to:
"The main objectives of this document are - 1) specify operational detail
for automatic tunneling IPv6 over IPv4 using ISATAP, 2) specify the
format of the interface identifier format using an embedded IPv4 address,
3) describe the operation of IPv6 Neighbor Discovery, and 4) discuss
deployment, and security considerations."
3) Add a definition of LinkMTU. "The MTU of the link."
4) Section 6.3.1. First paragraph.
ISATAP nodes should be ISATAP hosts.
5) Appendix D. 2nd paragraph. s/node/router/ The paragraph was confusing
initially as it used nodes instead of routers.
Btw, this new section contains another inconsistency - ISATAP link
instead of underlying link. I am not complaining though. ;-)
6) Since one of the main aims of the document is to specify deployment
considerations (see section 1), I feel we should make Appendix D as a
section in the document.