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

[Alain Durand <Alain.Durand@Sun.COM>]

[ post by non-subscriber.  with the massive amount of spam, it is easy to
 miss and therefore delete mis-posts.  so fix subscription addresses! ]

In the intoduction:

  The mechanisms in this document are designed to be employed by IPv6
  hosts and routers that need to interoperate with IPv4 hosts and
  utilize IPv4 routing infrastructures.  We expect that most nodes in
  the Internet will need such compatibility for a long time to come,
  and perhaps even indefinitely.

  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.

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.


  Modes of operation of IPv6/IPv4 nodes

       IPv6-only operation:

               An IPv6/IPv4 node with its IPv6 stack enabled and its
               IPv4 stack disabled.

       IPv4-only operation:

               An IPv6/IPv4 node with its IPv4 stack enabled and its
               IPv6 stack disabled.

       IPv6/IPv4 operation:

               An IPv6/IPv4 node with both stacks enabled.


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

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


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.


2.2.  DNS


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

=> 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]


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:

    1) The address is assigned to the interface on the node.

    2) The address is configured on the interface.

    3) The interface is on a link which is connected to the IPv6
       infrastructure.



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



4.1.  Ingress Filtering

  The decapsulating node MUST verify that the tunnel source address is
  acceptable before forwarding decapsulated packets to avoid
  circumventing ingress filtering [13].  Note that packets which are
  delivered to transport protocols on the decapsulating node SHOULD NOT
  be subject to these checks.  For bidirectional configured tunnels
  this is done by verifying that the source address is the IPv4 address
  of the other end of the tunnel.  For unidirectional configured
  tunnels the decapsulating node MUST be configured with a list of
  source IPv4 address prefixes that are acceptable.  Such a list MUST
  default to not having any entries i.e. the node has to be explicitly
  configured to forward decapsulated packets received over
  unidirectional configured tunnels.


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

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.

	- Alain.