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

From: Alain Durand <[email-masked]>
Date: Mon, 16 Sep 2002 19:06:54 -0700

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

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Wed, 18 Sep 2002 05:42:03 +0900

>      [This is an asumption made in NAT64]

	really depends on the API you are using.  by default, getaddrinfo
	should not return them.  with ai_flags = AI_V4MAPPED, you may get them.

>   Example, there is a telnetd listening on v4 and v6, but popd only

	i don't think extra rule is needed.  when multiple address (mixture of
	AAAA and A) are returned, client (like SMTP sender) should try to
	connect to all of them, just like when multiple A records are returned.
	so it is okay to have IPv4-only SMTP server running on top of
	IPv4/v6 dual stack node, and advertise both AAAA and A records.
	the client will try IPv6 connection, fails, and then try IPv4
	connection.

>   but this somehow contradic the text in the security considerations.

	why not?  tunnel ingress box (= 6to4 relay router) should be located
	at topologically-correct location.

>   using open relays such a 6to4 creates serious risks in the Internet.

	there also is another problem which applies to with configured tunnel
	as well.  malicious party can inject IPv6-over-IPv4 packet to tunnel
	endpoint, to inject any IPv6 traffic to the Internet anonymously.

itojun

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Wed, 18 Sep 2002 06:08:46 +0900

>I have seens instances where this is a problem.
>Some applications, like Netscape, only do name to address resolution once,
>by fear of ssl connection theft (don't ask me wy they do that).
>So if you contact a web site that is v6 aware, you'll get the v6 addresss.
>Then, if you contact a pop server that is v4 only on the host, the 
>connection
>will fail.

	then netscape won't work when some of the servers (like 66.218.71.83)
	are down when looking at www.yahoo.com.  i don't think this is IPv6
	problem, but problem in general with multiple address (A/AAAA)
	records.  i'm not sure where is the best forum to discuss this.

>How do you reconcile this with RFC3068 An Anycast Prefix for 6to4 Relay 
>Routers ?

	IPv4 (outer) source address of the packet can be different from
	the 6to4 anycast prefix (192.88.99.x).  RFC3068 doesn't specify
	what address should be used as IPv4 source.  maybe RFC3068 should say
	something about it ("don't use 192.88.99.x as IPv4 source").

	RFC3068 section 4.2:

>   The 6to4 relay routers that advertise the 6to4 anycast prefix will
>   receive packets bound to the 6to4 anycast address.  They will relay
>   these packets to the IPv6 Internet, as specified in [RFC3056].
>
>   Each 6to4 relay router that advertise the 6to4 anycast prefix MUST
>   also provide an equivalent IPv4 unicast address.  Packets sent to
>   that unicast address will follow the same processing path as packets
>   sent to the anycast address, i.e., be relayed to the IPv6 Internet.

itojun

; <<>> DiG 9.3.0s20020722 <<>> www.yahoo.com. a
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14538
;; flags: qr rd ra; QUERY: 1, ANSWER: 8, AUTHORITY: 10, ADDITIONAL: 0

;; QUESTION SECTION:
;www.yahoo.com.			IN	A

;; ANSWER SECTION:
www.yahoo.com.		1790	IN	CNAME	www.yahoo.akadns.net.
www.yahoo.akadns.net.	290	IN	A	66.218.71.83
www.yahoo.akadns.net.	290	IN	A	66.218.71.84
www.yahoo.akadns.net.	290	IN	A	66.218.71.86
www.yahoo.akadns.net.	290	IN	A	66.218.71.87
www.yahoo.akadns.net.	290	IN	A	66.218.71.89
www.yahoo.akadns.net.	290	IN	A	66.218.71.80
www.yahoo.akadns.net.	290	IN	A	66.218.71.81

;; AUTHORITY SECTION:
akadns.net.		161825	IN	NS	ZC.akadns.net.
akadns.net.		161825	IN	NS	ZD.akadns.net.
akadns.net.		161825	IN	NS	ZE.akadns.net.
akadns.net.		161825	IN	NS	ZF.akadns.net.
akadns.net.		161825	IN	NS	ZG.akadns.net.
akadns.net.		161825	IN	NS	ZH.akadns.net.
akadns.net.		161825	IN	NS	USE2.AKAM.net.
akadns.net.		161825	IN	NS	NS1-93.AKAM.net.
akadns.net.		161825	IN	NS	NS1-159.AKAM.net.
akadns.net.		161825	IN	NS	ZA.akadns.net.

;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(0.0.0.0)
;; WHEN: Wed Sep 18 06:03:18 2002
;; MSG SIZE  rcvd: 363

---

From: Alain Durand <[email-masked]>
Date: Tue, 17 Sep 2002 13:59:37 -0700

Sure can try to make Netscape to change (I did),
but I'm affraid that there are many other applications that do not walk 
through
the list of addresses returned by the DNS.

>	endpoint, to inject any IPv6 traffic to the Internet anonymously.
I agree, this is a general problem. Tunnel decapsulators are basically 
acting
as packet anomymiser... and defeat iTrace messages.

    - Alain.

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 20 Sep 2002 10:22:59 +0200 (CEST)

Thanks for the comments.

>       to Ipv6-only devices interoperating with IPv4 devices via some 

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.

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

>      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

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

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

> either IPv4 or Ipv6 as transport.

ok

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

> [...]

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?

> [..]

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

>    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