Hi, > 2. AFTR Deployment Considerations ... > IPv4. Although an operator can configure a dual-stack interface for > both functions, we strongly recommended to configure two individual > interfaces (i.e. one dedicated for IPv4 and one dedicated for IPv6) > to segregate the functions.
Can you clarify whether this means two physical interfaces or two logical software interfaces? > 2.1. MTU Considerations ... > For fragmentation problem shares among all the tunneling protocols, > this is not unique to DS-Lite. The IPv4 packet isn't over-sized, it > is the v6 encapsulation that MAY cause the oversized issue. I must confess I am a bit confused. The IPv6 minimum MTU is so much larger than 576 that I don't see how you can fail to support the IPv4 minimum MTU. OK, suspending my disbelief on that point: > So the > tunnel points are responsible to handle the fragmentation. In > general, the Tunnel-Entry Point and Tunnel-Exist Point should > fragment and reassemble the oversize datagram. I understand that, if DF is not set, the tunnel entry point (or more accurately, the IPv4 entity forwarding the packet into the tunnel entry point) should fragment the packet. But unless you are re-inventing SEAL, the tunnel exit point will just forward the fragments, won't it? > 2.2. Lawful Intercept Considerations Given RFC 2804, I suggest deleting this section. > 2.3. Logging at the AFTR The arguments in this section are pretty powerful, but I wonder whether they belong in v6ops, rather than in a more general analysis of CGN/LSN/NAT444 issues such as draft-ietf-intarea-shared-addressing-issues. > 2.6. Strategic Placement of AFTR ... > The AFTR architecture design, then, is mostly figuring out the > strategic placement of each AFTR to best use the capacity of each > public IPv4 address without oversubscribing the address or overtaxing > the AFTR itself. Although only a few studies of per-user port usage > have been done, an AFTR should be able to support 3000 - 5000 users > per public IPv4 address. I find this number astonishing. We know that 200 open ports per user has been reported as typical in some ISP secnarios; that suggests that even as many as 300 users per public adress is close to the limit. Regards Brian Carpenter _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
