Re: comments on draft-ietf-ngtrans-mech-v2-00.txt

[Erik Nordmark <Erik.Nordmark@Sun.COM>]

Thanks for the comments.

>    However, IPv6 may be used in some environments where interoperability
>    with IPv4 is not required.  IPv6 nodes that are designed to be used
>    in such environments need not use or even implement these mechanisms
> 
> 
> => This last paragraph could be read as a hint that IPv6 nodes do not 
> have to
>       implement dual stack if and only they it will never have to 
> interoperate
>       in any way with any IPv4 node.
>       I think that in its introduction, this document should not close 
> the door
>       to Ipv6-only devices interoperating with IPv4 devices via some 
> sort of relays.

The paragraph doesn't talk about that case.
It says that if interoperability with IPv4 isn't needed
the mechanisms in the spec aren't needed.

Having said that, I have no problem dropping the paragraph in question.

> 1.1 terminology
> 
>         IPv6-native address:
> 
>                 The remainder of the IPv6 address space.  An IPv6
>                 address that bears a prefix other than 0:0:0:0:0:0.
> 
> 
> 
> => It will be good to have a terminology to distinguish IPv6 addresses 
> that embed
>      IPv4 addresses for automatic tunneling purposes (6to4, Isatap) from
>      other 'regular' types of Ipv6 addresses.

I note that this specification doesn't need such a distinction.
Exactly what would you like to distinguish using some new terminology?


> => the word 'stack' is confusing here. Does it covers the kernel only or
>       does it cover the libraries and applications as well?
>      How to differenciate a node with an IPv6 kernel but no IPv6
>      application? Example: a v6 dual stack node with
>      a popd listening only on Ipv4 sockets?

The document in fact doesn't use the "IPv4 operation" etc terms, so I'll 
just remove those definitions

> => And even from a kernel perspective, the work 'stack enabled' is 
> confusing.
>      Does it mean that the kernel has code to process IPv6 packets?
>      Does it mean that an IPv6 address has been configured on an interface?
>      Is a node with only link local address configured operating in 
> IPv6/IPv4 mode?
>      What about loopback only?
>      What about a node listening to RA on an IPv4-only network where a
>      rogue IPv6 router is sending a bogus prefix?

Loosly the intent is to capture the fact that the code to handle IPv4 and
IPv6 is present, but only one of the two has been configured to be operational.
The IP layer can't operate without IP addresses, so at a minimum an address
needs to be assigned.

Do we need this to be more "exact" than this? Which things break or are
confusion if we omit to specify whether link-local only is "enabled"
or whether loopback only is "enabled"?

> 2. Dual IP Layer Operation
> 
>    The most straightforward way for IPv6 nodes to remain compatible with
>    IPv4-only nodes is by providing a complete IPv4 implementation.  IPv6
>    nodes that provide a complete IPv4 and IPv6 implementations are
>    called "IPv6/IPv4 nodes." 
> 
> => Same comment as above.

The intent is (or was) that this capture not only the IP layer but all
applications as well.
Any suggestions how this can be made more clear?

> 2.2.  DNS
> 
> 
> => This section should say that the actual DNS query can be done using
> either IPv4 or Ipv6 as transport.

ok

> => On an IPv6-only node, would it be correct for a resolver library
>       recieving only A answers for a name to address question to
>       pass the application an IPv6 address using the IPv4-mapped format?
>       [This is an asumption made in NAT64]

That is an API question, which I think is out of scope for this document.
[But I personally agree it would be correct.]

> 
> 2.3.  Advertising Addresses in the DNS
> 
>    The recommendation is that AAAA records for a node should not be
>    added to the DNS until all of these are true:
> 
> [...]
> 
> => I think a extra rule is needed: The applications have to be IPv6 ready.
>    (see my comment on IPv4/IPv6 operation).
>    However, what to do when some services are IPv6 ready and some are not?
>    Example, there is a telnetd listening on v4 and v6, but popd only
>    listen on v4?

In many cases that rule wouldn't be helpful; for instance a student might
right up a new IPv4 application and run it on my server - how am I as a system
admin supposed to know this?

I would make more sense add text pointing out the issue when (server)
applications on dual nodes do not support IPv6. What type of warnings would
you like to see?


> 4.1.  Ingress Filtering
> 
> [..]
> 
> => This only applies to configured tunnels, and CAN NOT be implemented
>    for automatic tunnels like 6to4 using relay routers.
>    I understand this is a sub-section of '4 Configured Tunneling'
>    but this somehow contradic the text in the security considerations.

What is the contradiction?
This document is about configured tunnels and not about 6to4.

> 6.  Security Considerations
> 
>    Tunneling is not known to introduce any security holes except for the
>    possibility to circumvent ingress filtering [13].  This is prevented
>    by requiring that decapsulating routers only forward packets if they
>    have been configured to accept encapsulated packets from the IPv4
>    source address in the receive packet.
> 
> => This is not true for automatic tunneling (see above comment)
>    I think that any kind of automatic tunneling mechanism
>    using open relays such a 6to4 creates serious risks in the Internet.

That is a good comment for the 6to4 document(s), but I don't see
how it applies to this document on configured tunneling.

  Erik