You can refer to RFC 2983 "Differentiated Services and Tunnels." (Informational RFC)
Regards Brian Carpenter On 2010-10-28 05:32, Lee, Yiu wrote: > Agreed. Thx. > > From: Jacni Qin <[email protected]<mailto:[email protected]>> > Date: Thu, 28 Oct 2010 00:19:42 +0800 > To: Brian E Carpenter > <[email protected]<mailto:[email protected]>> > Cc: Softwires <[email protected]<mailto:[email protected]>> > Subject: Re: [Softwires] I-D > Action:draft-lee-softwire-dslite-deployment-00.txt > > One more comment on Section 2.8, > > "...It is recommended the AFTR to copy the DSCP value in the IPv4 header to > the IPv6 header after the encapsulation." > > I guess a similar function is needed on B4 for the upstream traffic. Add it > somewhere in the B4 section? :-) > > > Cheers, > Jacni > > > > On Wed, Oct 27, 2010 at 10:13 AM, Brian E Carpenter > <[email protected]<mailto:[email protected]>> wrote: > 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]<mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/softwires > > _______________________________________________ Softwires mailing list > [email protected]<mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/softwires > _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
