[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments on draft-ietf-ngtrans-isatap-15.txt
Chirayu,
Thanks for the comments; responses are inline below:
Fred
ftemplin@iprg.nokia.com
Chirayu Patel wrote:
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.
Link layer address options are not used for ISATAP, but perhaps
we should mention this somewhere in the draft. The correct place
would seem to be section 6 (Neighbor Discovery).
I might be missing something obvious in this one as I have yet to read
RFC2491.
The RFC 2491 reference is non-normative and historical.
ISATAP is implemented independently of RFC 2491.
2) Section 4.3 (draft 15). 1st paragraph.
ISATAP interfaces recognize an IPv6 node's required addresses
^^^^^^^^^
What does the word "recognize" imply?
This sentence continues with a normative reference to
([RFC3513, section 2.8), and that section begins as:
+ 2.8 A Node's Required Addresses
+
+ A host is required to recognize the following addresses as
+ identifying itself:
So, the word "recognize" implies the same thing that it implies
in the normative text in RFC 3513.
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."
We can consider bringing "ISATAP link" back into the terminology
section, but your proposed definition does not capture the fact that
more than one underlying link may belong to the same ISATAP link.
We've been down this path before; in drafts -12 and earlier we
defined the following terms:
+ underlying link:
+ a link layer that supports IPv4 (for ISATAP), and MAY also
+ support IPv6 natively.
+
+ ISATAP link:
+ one or more underlying links used for tunneling. The IPv4
+ network layer addresses of the underlying links are used as
+ link-layer addresses on the ISATAP link.
+
+ ISATAP interface:
+ a node's attachment to an ISATAP link.
So, if you want "ISATAP link" brought back into the terminology
section let's work from the above definitions and refine them as
needs-be. Suggestions?
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.
Points a) and b) sound fine, but we tend to disagree on point c).
Some ISATAP sites may by design have no routers in the PRL
at all. For other sites, PRL membership changes would most
likely be a rare occurrence and coordinated so as to avoid service
disruptions. In either case, introducing a finer-grained PRL
refresh interval would only lead to traffic scaling issues.
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) ?
We want nodes to solicit fresh RAs *before* any lifetimes
expire, and (0.5 * MIN_LIFETIME) seems a reasonable
way to assure this.
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.
Well, in section 6.3.4.1 we have the sentence: "The manner of selecting
PRL(i)'s for solicitation is up to the implementation.", and we imply
the same behavior here. We can consider adding a sentence such as
the following to section 7:
+ The manner of selecting a PRL(i) is up to the implementation.
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?
No; we agree that the simplest scenario is for the DHCPv6 server(s)
to be co-located on the PRL router(s). ISATAP is intended as a
simple mechanism.
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?
Section 4.3 says that multicast emulation is out of scope meaning
that it would be specified in another document, i.e., we believe
nothing more needs to be said in the ISATAP draft.
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.
"not required", as in: "OPTIONAL, but out of scope for this document".
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 |
\____________/
Your network view is correct, but ISATAP hosts may
communicate with non-default routers. Hosts may receive
a redirect with a non-default router as the target, or may
otherwise discover a route for a more specific prefix than
"default" that has a non-default router as the next hop.
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."
Have rec'd other comments to the effect that "...no requirement for
IPv4 multicast" opened an undesireable can of worms. We can
consider inserting the term "NBMA" as in:
+ ISATAP treats the site's IPv4 unicast infrastructure as a NBMA
+ link layer for IPv6.
But, this seems like a very minor change.
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."
Agree with your suggested re-word.
3) Add a definition of LinkMTU. "The MTU of the link."
The first mention of LinkMTU references ([RFC2461, section 6.3.2),
and we expect the reader to visit that normative text, so we see this
as a low-priority item. If you really think LinkMTU belongs in the
terminology section, we can consider adding it as:
+ LinkMTU:
+ same as defined in ([RFC2461], section 6.3.2)
4) Section 6.3.1. First paragraph.
ISATAP nodes should be ISATAP hosts.
The first sentence of (RFC2461, section 5) says: "This section
describes a conceptual model of one possible data structure
organization that hosts (and to some extent routers) will
maintain...", so we really do mean to say nodes (i.e., hosts
AND routers) here. To make things clearer, however, we can
consider the following re-write for the first sentence of 6.3.1:
+ ISATAP hosts (and to some extent routers) use the conceptual
+ data structures specified in ([RFC2461], section 5.1).
5) Appendix D. 2nd paragraph. s/node/router/ The paragraph was confusing
initially as it used nodes instead of routers.
Well, you were able to draw the network diagram correctly
above, so you clearly derived the correct meaning. Your point
is taken, but this seems a rather minor detail.
Btw, this new section contains another inconsistency - ISATAP link
instead of underlying link. I am not complaining though. ;-)
See above.
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.
Do you mean appendix C, perhaps? Tend to disagree,
because there is no normative text in that section, and to our
understanding non-normative text belongs as an appendix.