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

From: Brian E Carpenter <[email-masked]>
Date: Thu, 22 Jul 2004 12:05:57 +0200

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

---

From: Fred Templin <[email-masked]>
Date: Mon, 26 Jul 2004 15:46:57 -0700

Brian,

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

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

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

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

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

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

> 6to4 prefixes (e.g. belonging to several different ISPs or several 

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

Thanks - Fred
[email-masked]