[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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

Jun-ichiro itojun Hagino wrote:

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

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.

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.

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

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.
I agree, this is a general problem. Tunnel decapsulators are basically acting
as packet anomymiser... and defeat iTrace messages.

- Alain.