> v6 reassembly works fine on BSD. Must be an issue with translation. > Do you see any ICMPv6 error mesgs being generated by BSD ? > No, there are no ICMP errors generated by FreeBSD. > Is ::192.168.1.2 a valid source addres on a non-tunnelled IPv6 packet ? Are you not >using any NATPT prefix to denote the Ipv4 address ?? We are using a '::' prefix to denote IPv4 addresses. It works fine when not using fragmented packets. > > regds > sukhdeep > > > >>> "Juan Luis Baptiste" <[EMAIL PROTECTED]> 01/30/03 11:11PM >>> > Hi, > > I'm working in a NAT-PT and I'm having some trouble translating IPv4/IPv6 fragmented >packets. > > I have the following setup: > > +--------+ Seg.3 +--------+ Seg.2 +-------+ Seg.1 +-------+ > | Host C |-------| NAT-PT |--------|Host B |-------|Host A | > | FreeBSD| | Linux | |FreeBSD| |Linux | > +--------+ +--------+ +-------+ +-------+ > IPv6 IPv4 IPv4 > MTU=1500 MTU=100 MTU=1500 > > When host A tries to reach host C, the fragmented packets are apparently well >translated by the NAT-PT router according to SIIT (RFC 2765). Looking with a sniffer in segment 2 and 3, you see that each of the fragments are translated, I don't see any error in the new IPv6 packets, but the IPv6 host doesn't seems to reensamble the fragments, because the host never sends an ack back. > > Whaty could it be happening? could it be an error in the translation procees that we >haven't found or an issue with the handling of IPv6 fragmented packets in FreeBSD? > > Here I send the capture of the first packet and how is translated. The rest of the >fragments are translated in the same way: > > Internet Protocol > Versión:4 > Header Length: 20 bytes > DSF:0x10 > Total Length:100 bytes > Identification: 0x02fc > Flags: 0x02 > 0 = Don’t fragment: no set > 1 = More fragments : set > Fragment offset: 0 > Time to live: 63 > Protocol: TCP (0x06) > Header checksum: 0x95dd (correct) > Source: 192.168.1.2 (192.168.1.2) > Destination: 1.0.0.1 (1.0.0.1) > Transmission Control Protocol > Source Port: telnet (23) > Destination port : 1027 > Sequence number : 3853395892 > Next sequence number : 3853395940 > Acknowledgement number: 3252790475 > Header Length: 32 bytes > Flags: 0x0010 (ACK) > Windows size: 32844 > Checksum: 0x904b > Options: (12 bytes) > Telnet > Data: vecore\r\n > Data: comcontrol\tifconfig\tmount_cd9660\tnewfs\t\t > > > Ej. Paquete fragmentado IPv6 traducido. > > Internet Protocol Version 6 > Version: 6 > Traffic Class: 0x00 > Flow Level: 0x00000 > Payload Length: 88 > Next Header: IPv6 Fragment (0x2c) > Hop Limit: 127 > Source address: ::192.168.1.2 > Destination Address: 3ffe:1ce1:2:0:200::2 > Fragmentation Header > Next Header: TCP (0x06) > Offset: 0 > More fragments: YES > Identification: 0x000002fc > Transmission Control Protocol > Source Port: telnet (23) > Destination port : 1027 > Sequence number : 3853395892 > Next sequence number : 3853395940 > Acknowledgement number: 3252790475 > Header Length: 32 bytes > Flags: 0x0010 (ACK) > Windows size: 32844 > Checksum: 0xfd4f > Options: (12 bytes) > Telnet > Data: vecore\r\n > Data: comcontrol\tifconfig\tmount_cd9660\tnewfs\t\t > > > Thanks for any hint on this. > > Cheers, > > > -- > ------------------------------- > Juan Luis Baptiste M. > Linux registered user #119248 > http://www.merlinux.org > > "we're back to the times > when men were men and > wrote their own drivers" > Linus Torvalds > ------------------------------- > -- > ______________________________________________ > http://www.linuxmail.org/ > Now with e-mail forwarding for only US$5.95/yr > > Powered by Outblaze > --------------------------------------------------------------------- > The IPv6 Users Mailing List > Unsubscribe by sending "unsubscribe users" to [EMAIL PROTECTED] > -- ______________________________________________ http://www.linuxmail.org/ Now with e-mail forwarding for only US$5.95/yr
Powered by Outblaze --------------------------------------------------------------------- The IPv6 Users Mailing List Unsubscribe by sending "unsubscribe users" to [EMAIL PROTECTED]
