Re: transmech substantial comments

[Erik Nordmark <Erik.Nordmark@sun.com>]

> 1) section 2.3 on advertising addresses in the DNS is a bit out of place in
> this document.  If there was some other doc describing how to provision
> services with addresses in the DNS, the discussion would be best placed
> there.  Can anyone think of such a document?  

I don't know of such a document.

> In any case, I believe we need an additional recommendation, that a node
> should not be added in the DNS before all the externally visible services
> are supported (e.g., there should not be an AAAA record for foo.example.com,
> until foo (an IMAP/SMTP server) supports both IMAP and SMTP over v6). 
> Alternatively, service names instead of node names can be used.

I can add this.

> also move the paragraph starting with "A possible implication" up before
> the previous paragraph, as "A possible..." as it seems like a more logic
> place for it.

Don't understand where you think it belongs; the several preceeding paragraphs 
follow on eachother. Which paragraph do you think it should preceed?

> 2) I believe unidirectional tunneling should be removed.  Note that it seems
> it has been used in three different meanings in the document:

This is one issue I want explicit WG feedback on tomorrow.
I don't have a problem removing them - it would simplify the text.

> So, because the first definition is obviously closer to the mark:
>   - unidirectional tunnels with the first definition are a remnant of
>     automatic tunneling, and can be removed.

That is definitely part of the reason for the explicit mention, but
I don't know if it the only reason.

>   - the bidirectionality rules need to be reworded and described
>     better, and we may have to beef up the source address selection part of
>     a tunnel a bit.

Yes, if we remove the unidirectional tunneling text then the IPv4 source
address at the encapsulator can be described as something which is configured
since both ends of the tunnel need to have matching IPv4 addresses for the
tunnel.

> 3) do we need to add the following kind of clarification to section 3.2.1 as
> a caveat on fixed MTU use?  
> 
>    One should note that even though MTU of a tunnel on a node is limited to
>    e.g. 1280 bytes, the nodes still must be able to process larger received
>    packets, in case that the peer has configured a higher MTU or if the peer
>    is using dynamic MTU detection.

I could add this.

>  4) We specify the that the ToS byte for the v4 header is 0 unless otherwise
> specified, and refer to a couple of documents for that.  A problem with this
> is that I'm not sure if those documents actually tackle the problem of
> *different* protocol-version tunnels -- rather, they (AFAIR) discuss the
> issues of ToS byte in v4-over-v4, where mapping (or not mapping) the ToS
> byte from the inner IP header is a trivial excercise.
> 
> I fear that we may have to specify the rules for setting the ToS byte
> ourselves, or at least give more guidance on that.

I don't see why we'd need to do that. Tunnels, using the same versions or
different versions, can cross a region where the DSCP is interpreted
differently thus the issues whether to copy the DSCP when encapsulating is
identical AFAIK.

For the congestion bits the same considerations apply whether the IP versions
are the same or different.

So do you have a concrete argument that we need explicit text on this?
(If we want this to move to DS sooner rather than later I think we should
avoid this.)

>  5) As a consequence from the move to bidirectional tunnels (I hope..), I
> think we will need stronger text than what's in 3.5:

Yes, if we remove the unidirectional tunnels it makes sense making this
more explicit.

>  6) the ingress filtering sections in 3.6 need beefing up a bit, reword:

Done.

> 7) Security considerations should be better in two aspects:
>   * the first sentence states:
> 
>    Tunneling is not known to introduce any security holes except for the
>    possibility to circumvent ingress filtering [RFC2827].
> 
> .. this is not correct, as noted later in this section on the attacks
> against the pseudo-interface.

ok; I'll rephrase.

>  * there should be text what to do if the current tradeoffs of configured
> tunneling are not considered to be OK, in:

Instead of claiming that GRE with keys (which are in RFC 1701 but not part of
RFC 2784) is much secure, how about instead saying that AH/ESP can be applied
to the tunnel?

   Erik