Subject: RE: Comments on draft-ietf-ngtrans-isatap-15.txt

From: "Chirayu Patel" <[email-masked]>
Date: Wed, 17 Sep 2003 19:17:49 +0530

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

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. 

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

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

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

>>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. 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 RA’s to all of them.

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

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

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

==> "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.

Also s/from perform/from performing/

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

You have reached the end! :-)

---

From: Fred Templin <[email-masked]>
Date: Wed, 17 Sep 2003 11:45:28 -0700

CP,

Responses are inline below:

Fred
[email-masked]

>The text in section 3.8 RFC 2893 seems appropriate

Or something similar, perhaps.

>then the format of the link-layer address must be specified.

Then, this seems like an issue for RFC 2893/MECH(bis).

>"certain multicast/anycast addresses". Right? Or, am I missing something?

OK.

>Assume the following stack in an ISATAP node.

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.

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

>proactively vis-`-vis periodic RS from the host for new information. The
>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
>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).

>provide a reference. IMHO, it improves the readability of the document.

OK.

>routers. This section confused me. My vote is to modify it.

OK.

>using RFC 3041 src address (instead of ISATAP addresses)?

Given proper configuration, yes.

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

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