Re: transmech substantial comments

[Pekka Savola <pekkas@netcore.fi>]

On Tue, 11 Nov 2003, Erik Nordmark wrote:
> > 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.

Now that I think about it, draft-ietf-dnsop-ipv6-dns-issues-02.txt at 
least could b expanded to include more guidelines rather than issues.  
I'll consider 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?

It seems to me that the paragraph starting with "Since the.." starts to 
describe a separate problem.  There are two issues here AFAICS:

 1) an ipv6 node is placed on a link "prematurely", and advertises its 
address in the DNS.

 2)  an ipv6 node without connectivity tries to reach a node by getting a 
AAAA record from DNS, and

The general tone of a "A possible implication" -section seems to address 
1) only, while the preceding paragraph discusses 2).  So, saying 
"implication of these recommendations" seems to either belong after 1) 
(because it only covers 1), or reworded to be a bit more general.

Right?

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

Right. (There is an obvious failure mode with multiple interfaces and a 
change in where the route towards the tunnel endpoint points to, of 
course -- which why it probably needs to be spelled out better as 
spelled out later.)
 
> 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.)

No, I don't have a specific arguments.  It just looked like a potential 
hole in the spec.  But I'm OK with leaving it vague.
 
> >  * 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?

One could say one or the other, or both (if they are actually more secure, 
which I'm not 100% sure about).

My concern is just that setting up a GRE tunnel instead of IP-IP tunnel is 
typically fully equivalent (subject to a trivial modification to the MTU 
usage parts), and configured similarly.

IPsec is of course a proper way to do it, but AFAIK it hasn't been
implemented (v4-in-v6 IPsec, that is) -- that's at least what Francis
Dupont has been saying (unless I misremember the context)...

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings