[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments on draft-ietf-ngtrans-isatap-15.txt
CP,
Responses are inline below:
Fred
ftemplin@iprg.nokia.com
Chirayu Patel wrote:
Hi Fred,
Thanks for the detailed reply. Please see comments below.
CP
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).
Agreed.
The text in section 3.8 RFC 2893 seems appropriate
Or something similar, perhaps.
The only confusing part is that RFC 2893 assumes that tunnel end points
do NOT have link-layer addresses. However it also mentions that SLLA, and
TLLA options *SHOULD* (instead of MUST) not be filled. I can't think of
any reasons behind the *SHOULD*. In case there is a legitimate reason,
then the format of the link-layer address must be specified.
Then, this seems like an issue for RFC 2893/MECH(bis).
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.
The wording is a bit different, hence the confusion. It is not the
interface that recognizes but the host (or the IPv6 layer on the host).
The correct wording should be "A node is required to recognize an IPv6
node's required addresses (RFC[3513], section 2.8). No need to mention
"certain multicast/anycast addresses". Right? Or, am I missing something?
OK.
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?
Hmm....I did not think about this one. Maybe the definition can be
improved. I'd rather not open my mouth until I get some confirmation from
you that my understanding is correct.
Assume the following stack in an ISATAP node.
+-----------------------------+
| IPv6 |
| |
+-----------------------------+
| ISATAP i/f |
| |
+-----------------------------+
| IPv4 |
| |
+-----------------------------+
| +----------+ +-----------+|
| | Phy i/f 1| |Phy i/f 2 ||
| +----------+ +-----------+|
+-----------------------------+
In this diagram, based on the above definitions,
1) Number of underlying links will be 2. Assume two IP addresses one for
each underlying link - IPv4A, and IPv4B.
2) Number of ISATAP links will be 1.
3) Number of ISATAP i/d's will be 2 - 0000:5EFE:<IPv4A>, and
0000:5EFE:<IPv4B>
4) Number of IPv6 link-local addresses will be 2.
5) Number of IPv6 addresses for n prefix's received from the routers in
PRL will be 2*n.
Is my interpretation accurate?
This needs to be broken out into a seperate discussion thread
which may indeed be out of scope for v6ops. Let's take this
off-list in private e-mail.
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.
You are right. Some sites may have no routers. For those sites, the PRL
should be empty. Incase the PRL is not empty there should be a more
sophisticated mechanism, like router discovery maybe.
That said; I am actually not able to make up my mind on the level of
detail we should go into. Some of the things that are bothering me are:
1) The PRL mechanism is out of scope. It could be a "push" or a "pull"
mechanism or both "push and pull". (Push = when a server can push changes
to the client. For example, DHCP. Pull = when a client queries and gets
the data from the server. For example, DNS.)
2) PRL refresh by the client is needed only for "pull" mechanisms. Some
pull mechanisms have built in refresh. For example TTL in DNS.
3) PrlRefreshInterval seems to cover all types of mechanisms "Push",
"Pull", and both "Push and Pull". Its use should be restricted in cases
where there is no inbuilt timer.
Hence, I propose that we
1. Specify the cases where PrlRefreshInterval will be useful. 2. Specify
the mechanism for discovering the PRL when no routers are available.
Incase you do agree then I can mail some sample text.
Certainly send the sample text (off-list preferred), but we don't yet
agree that there is any issue with the current specification.
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.
Got it!
RFC 2461 uses periodic RA's from routers to propagate information
proactively vis-`-vis periodic RS from the host for new information. The
periodic RA's are however sent to multicast address. It means that that
periodic RA's cannot be sent out by an ISATAP router.
No; it means that periodic RA's sent to All-Nodes multicast will
not be received by all ISATAP nodes unless a multicast emulation
mechanism is used, which is out of scope for the isatap draft.
Just curious, have
you guys considered an approach wherein a router would remember all the
hosts from which it has received RS in the past, and would unicast
periodic RAs to all of them.
This is one possible example of a multicast emulation mechanism
(i.e, out of scope for the isatap draft).
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.
Agreed.
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.
Got it.
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.
Agreed.
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".
Ok.
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.
More comments on this one below.
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.
Ok.
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)
My preference is not to repeat definitions from normative references.
However, the definition section should mention all the used terms, and
provide a reference. IMHO, it improves the readability of the document.
OK.
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).
Ok
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.
I strictly follow the definition of "node" (2461 terminology), and
interpret text containing "nodes" in the context of both hosts and
routers. This section confused me. My vote is to modify it.
OK.
I have few more doubts in this section:
==> "the ability for ISATAP nodes to send IPv6 packets with non-ISATAP
source addresses (e.g., RFC 3401 privacy addresses),"
What does this imply? ISATAP hosts can send out IPv6-in-IPv4 messages
using RFC 3041 src address (instead of ISATAP addresses)?
Given proper configuration, yes.
==> "But, allowing this functionality prevents ISATAP nodes from perform
effective ingress filtering for IPv6 source addresses in packets they
receive."
The functionality being referred in the above sentence is "flexibility to
have more routers than those in the PRL". What prevents these non-default
nodes (routers) from doing effective ingress filtering? Like other
routers, they too can be configured with the same prefixes.
Suppose non-PRL router A sends packets to ISATAP host B with
an IPv6 source address prefix that is not on-link with the ISATAP
link and not otherwise known to B, e.g., via a routing table entry.
B has no basis for trusting A at the IP level, so B has no way of
performing ingress filtering to determine whether A (or some
node for which A is the router) is using a spoofed IPv6 source
address. Thus, the trust basis must be at the link level if we are
to allow non-PRL routers.
Also s/from perform/from performing/
OK.
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.
Ok.
On the topic of address selection, I am sure that it has been discussed
in the past. Policy table modifications do not seem to be
straightforward. Do you think it would be useful to mention whatever
outcome there has been in the past on address selection?
Address selection considerations are the same as for any IPv6
link, modulo further discussion on the definition of ISATAP link.