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

Re: I-D ACTION:draft-templin-v6v4inet-00.txt

Fred, I'm not sure which list this belongs on, so I chose v6ops.

I have a few comments and questions.

Abstract

IPv6 includes a 128-bit address space designed as a solution for the
32-bit limitation of IPv4. But, IPv4 proliferation in the global
Internet continues via private addressing domains behind Network
Address Translators (NATs). Furthermore, a formerly popular
viewpoint that IPv6 networking would soon replace IPv4 seems to be
yielding to an emerging viewpoint of long-term coexistence. 

I really have problems with the last sentence. I can't imagine where
such a "popular viewpoint" ever existed. Speaking personally, I've
been on a coexistence model since RFC 1671.

4. Inter-Enterprise Communications

   When an ISATAP node sends ip-protocol-41 packets toward an IPv6
   target node located in a remote enterprise, the virtual link can
   theoretically extend all the way from the sender to the target's
   enterprise border (or even to the target itself) given appropriate
   enhancements in RPBSs along the path as follows:


Either I have read the document carelessly, or it doesn't explain
anywhere by what magic the path between the RPBSs is formed. Do they
run normal IPv6 routing protocols, or what?

4.1 From the Sender to the Target's Enterprise Border

   Any RPBSs along the path from the sender to the target's enterprise
   border that rewrite a packet's IPv4 source address should implement a
   simple enhancement to support extension of the virtual link. In
   particular, each such RPBS should also rewrite any matching IPv4
   addresses embedded in the packet's IPv6 source address and (for IPv6
   Neighbor Discovery messages) in Source/Target Link Layer Address
   Options [RFC2529] at the same time the IPv4 source address is
   rewritten (i.e., an operation commonly referred to as proxying
   [NDPROXY]).


This appears to describe an IPv6 NAT process. If so, surely we must deem
it unacceptable. We want packets to be delivered unchanged in IPv6.

Each such RPBS should also cache IPv6 flow soft state [RFC3697]... 

RFC 3697 doesn't discuss soft state. It specifically says that "The nature
of the specific treatment and the methods for the flow state establishment
are out of scope for this specification."

   ...as a
   logical interface identifying the sender and take care that no two
   flows with the same (IPv4 src, IPv4 dst, IPv6 flow_label)-tuple exit
   the enterprise/site at the same time.   If two or more flows attempt to
   use the same (non-zero) IPv6 flow label and IPv4 destination address,
   an RPBS can break the tie by assigning distinct IPv4 addresses to the
   flows when it re-writes the IPv4 source address and matching IPv4
   addresses in ip-protocol-41 packets. (This requires each RPBS to
   assign multiple IPv4 addresses to its outgoing interfaces.)


Well, the RFC 3697 requirement for flow labels is only that the
(IPv6 src, IPv6 dst, IPv6 flow_label) tuple must be unique. That is a
much easier constraint to meet. If the IPv4 addresses in question
are to be taken from a NAT pool, I don't think this will scale at all.
What if a site generates 20000 simultaneous flows to different clients?
It's quite consistent with RFC 3697 for them to use the same flow label.

6. Addressing

   When an ISATAP node's application initiates communications with a
   target peer, it first resolves the target's Fully-Qualified Domain
   Name (FQDN) using the DNS [RFC1035] or an enterprise-internal name
   service, e.g., [LLMNR]. If the name service returns a set of AAAA
   records including one with a 6to4 [RFC3056] subnet router anycast
   address, ...

I don't understand why that would ever happen.

   ...the initiating node can use the IPv4 address embedded in the
   6to4 prefix as the IPv4 destination address for the target node's
   enterprise border RPBS. (The address can also be used to determine
   whether the initiator and target reside in the same enterprise.)


No it can't, in the general case. A site might run multiple simultaneous
6to4 prefixes (e.g. belonging to several different ISPs or several different
border routers).

Regards,

Brian