Subject: [BEHAVE] draft-baker-behave-v4v6-framework-00

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 11 Nov 2008 13:13:23 +0100

This is my review of draft-baker-behave-v4v6-framework-00.

It's too wordy. Please make it more concise. A reduction in creative  
turns of phrase also wouldn't hurt.

    o  We also need a technology that will allow peers to connect with
       each other, whether in the IPv6->IPv4 direction or the IPv4->IPv6
       direction.  Again, it would be ideal if this was stateless, but a
       stateful algorithm is acceptable if the complexity is minimized
       and a stateless algorithm cannot be constructed.  In the case of
       infrastructure applications, which know nothing of choosing among
       peers by reputation, the IPv4->IPv6 direction is a stronger
       requirement.

I don't understand why this would be a (stronger) requirement.

Also, I wouldn't characterize SMTP as peer-to-peer, but rather as  
client-server where the roles of clients and servers can be reversed.

My classification of peer-to-peer applications is those where there is  
no need to connect to a given peer, but just a reasonable selection of  
peers (e.g., BitTorrent) versus those where any/all peers must be  
reachable (e.g., SIP).

What does "IPvX-only island" mean? A part of the global IPvX network  
where there is no IPvY? Or a network that runs IPvX with no  
connectivity to the IPvX internet but only the IPvY internet? Note  
that the latter is highly problematic, because hosts that have an IPvX  
address and an IPvX default route and see IPvX addresses in the DNS  
assume that they can reach the destination in question over IPvX.

Why the extensive examples? A framework should be general, not bog  
down complex addressing.

    Since [RFC4291] specifies that IPv6 prefixes are 64 bits or shorter
    apart from host routes, one wishes to allocate each customer a /64
    mapped to a few IPv4 addresses and a shorter prefix for his general
    use.

What does this mean??

The mapped address format is unworkable:

* It seems to be optimized to import IPv4 routing into IPv6 routing.
   Which is a thing we want/should avoid.

* Using a /40 in every ISP, or even several of those, wastes a lot of
   IPv6 address space.

* If bits of the IPv4 address are going to be in the upper 8 bits of
   the interface identifier they clash with the unique/local and group
   bits which means that this type of addressing is incompatible with
   normal use of a subnet, and without normal use of a subnet there is
   no point in having the IPv4 space spread over multiple /64s as far
   as I can see.

* Not having the IPv4 bits in a fixed place means translators will
   have to be more complex.

    o  Application Layer Gateways for some applications

Disagree. ALGs tend to cause problems, current thinking is that the  
applications should work around translation issues. In the NAT44 case  
there are old applications that don't work without ALGs. Those  
applications can't realistically be supported by NAT64 (or NAT46)  
anyway. If both ds-lite and some form of NAT64 are specified, it's  
highly desirable that ds-lite be optimized for backward compatibility  
(and thus run ALGs, which can then be existing NAT44 ALGs) while NAT64  
be optimized for forward compatibility and NOT use ALGs (which would  
have to be reinvented for the NAT64 case at significant cost, anyway).

    IPv4 servers and peers in a scalable fashion, supporting  
aysnchronous
    routes.

What are asynchronous routes?

    mode.  However, the designers of FTP inexplicably wrote different  
and
    incompatible passive mode implementations for IPv4 and IPv6  
networks.
    Hence, either they need to fix FTP, or a translator must be written
    for the application.

EPSV can also work with IPv4 so if all FTP servers are upgraded to  
support EPSV that would solve the problem. Then again, yesterday I  
found myself in need of a Dell printer driver which was available from  
an FTP server that doesn't seem to support passive mode at all  
(although it looks like the protocol is firewalled rather than not  
implemented).

    Just say "multicast"; this framework could support multicast, but at
    this point does not.  This is a place for future work.

In my opinion, we shouldn't try to support multicast translation.  
There is no internet-wide multicast service today, so the issue with  
IPv6 clients wanting to connect to services that are only available  
over IPv4 doesn't occur. Localized multicast services and be made  
available over IPv6 as required.

    Interoperation between IPv4-only clients and IPv6-only clients is  
not
    supported, and is not believed to be needed.

Earlier, client-to-client communication is defined as non-existant.

    TCP/UDP checksums  Using an operator-specified prefix requires the
       translator to adjust TCP and UDP checksums.

If there are 16 bits that can be modified in the prefix (which is the  
case with a /96 prefix, simply make it a /80 prefix) then this can be  
avoided. However, the NAT functionality requires updating the  
checksums anyway.

Please also include ICMP and DCCP.

I don't think the use of "RIR prefix" is appropriate. This implicitly  
excludes the possibility of using ULAs for this, which seems like a  
natural choice of an operator selected prefix.

    Routing  Routing is readily handled in the IPv4 network.  However,  
if
       routing of IPv4-mapped prefixes is desired in the IPv6 network,  
we
       are forced to use prefixes in the neighborhood of /96../128.
       Apart from routing host addresses, [RFC4291] frowns on this,
       preferring routing prefixes to be 64 bits or shorter and  
leaving a
       64 bit host ID.

Why would it be necessary to route part of the translated IPv4 space  
to another place than the rest of the translated IPv4 space?

In general, this part of the draft seems weak and contains a lot of  
internal redundancy which makes it hard to read and understand.

_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave