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

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

Brian,

Thanks for the comments; please see below for some follow-up:

Brian E Carpenter wrote:

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.



I can agree that the assertion is at least debatable, so I'm sure I can
find some replacement text that would set a less contentious tone.


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?



Section 4.2 touches on this when it says:

 "...each enterprise/site border RPBS along the path toward the final
  destination should use some form of static/dynamic route discovery
  to determine the next hop RPBS (or, the final destination itself)
  among their associated hosts."

and mechanisms to support the proposed: "static/dynamic route
discovery" are touched on in section 3.

I see at least two possibilities for the way RPBSs within an enterprise
can determine the IPv6 next-hop, and the method chosen could be at
the discretion of the individual enterprise.  In the first method, the
enterprise's RPBS could use some form of prefix delegation (perhaps
using DHCPv6) to form an hierarchical tree rooted at the enterprise
border(s). The (static) prefix delegation maps would then steer
IPv6 next-hop determinations.

In the second method, the RPBSs would run some form of dynamic
link-state routing algorithm to determine full/partial topology for
the enterprise, and associated hosts would be discovered via on-demand
route discovery. In this case, prefix hierarchies might not be necessary,
and the entire enterprise could be regarded as a "flat" topology. 

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.



I have been "on the fence" as to whether IPv6 header field rewriting
is strictly required, and I believe you are right that there are ways
that it can be avoided.

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.



What you seem to be identifying here is a "NAT vs. NAPT" issue.
RFC 3697 mandates that the flow-label not change along the path
to the destination, so RPBSs would need to resolve "collisions" by
assigning different IPv4 source addresses for colliding flows as
for NAT without port translation. An alternative would be to provide
a "mutable" field in the packet that can be rewritten by RPBSs along
the path that act as NAPTs.

The most obvious approach is to use IPv6/UDP/IPv4 encapsulation (i.e.,
as for 'teredo'), which already provides the UDP source port as a mutable
field for NAPT and presents the approach of least surprise for legacy
equipment. However, it requires that the 8-octet UDP header be present
in all encapsulated packets which might not interact well with paths
having severely-constrained MTUs and requiring significant fragmentation.

A second NAPT alternative would be to use 'ip-protocol-41' encapsulation
but disable IPv4 fragmentation by setting the "DF" bit in the IPv4 header
and treating certain other fields as mutable. Using this approach, an
encapsulating RPBS could set the 13 "fragmentation offset" bits, the 16
"ID" bits, and possibly also the "More Fragments" bit to a unique value
corresponding to an (IPv6 src, IPv6 dst, IPv6 flow_label)-tuple. The resulting
(IPv4 src, IPv4 dst, mutable_bits)-tuple would then serve as a "virtual circuit
identifier" that can be rewritten by enlightened RPBSs acting as NAPTs in
the path. The intermediate RPBSs and final decapsulator would also require
a bit in the IPv4 header to indicate that the above-mentioned IPv4 header
fields are being used as a virtual circuit identifier, and the "Reserved
Fragmentation" bit could be used for that purpose.

The primary disadvantage of the latter approach is that it effectively
disables IPv4 fragmentation since the DF bit is set in all packets. This
would be at odds with paths that do not support at least the minimum
IPv6 MTU of 1280 bytes, since links for IPv6 must be able to deliver
a 1280 byte packet without returning a "Packet too big" error. To avoid
this issue, an "adaptation layer" for 'ip-protocol-41' would be needed
whereby encapsulated packets are fragmented/reassembled at an
intermediate level between IPv6 and IPv4. Packets on the wire would
appear as whole IPv4 packets with the "DF" bit set, and IPv6 fragments
would possibly be carried in multiple 'ip-protocol-41' packets. But,
the intermediate adaptation layer would be opaque to both IPv6
(as seen from above) and IPv4 (as seen from below).

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. 


A means for associating a node's IPv6 address(es) with a global IPv4
address for its home enterprise is required, and it would be desirable
to discover this association during name resolution.

An alternative to asking nodes to configure a 6to4 subnet router
anycast address for its home enterprise in the DNS RR's would
be to simply have them configure real 6to4 unicast addresses. This
would seem like a reasonable requirement for RPBSs, but perhaps
not for IPv6-only nodes. This leaves us with a question as to how
(and whether) IPv6-only nodes can be associated with a global
IPv4 address for their home enterprise?

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


Agreed; this point was more of a tangential observation than
an architectural requirement anyway.


Thanks - Fred
ftemplin@iprg.nokia.com

Regards,

Brian