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

[Jun-ichiro itojun Hagino <itojun@iijlab.net>]

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

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

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

	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.

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

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

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

	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