[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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! ]
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
implement dual stack if and only they it will never have to
in any way with any IPv4 node.
I think that in its introduction, this document should not close
to Ipv6-only devices interoperating with IPv4 devices via some
sort of relays.
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
IPv4 addresses for automatic tunneling purposes (6to4, Isatap) from
other 'regular' types of Ipv6 addresses.
Modes of operation of IPv6/IPv4 nodes
An IPv6/IPv4 node with its IPv6 stack enabled and its
IPv4 stack disabled.
An IPv6/IPv4 node with its IPv4 stack enabled and its
IPv6 stack disabled.
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
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
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.
=> 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
=> 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 . 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 . 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.