Re: [Softwires] Draft 4rd-u-05 is available

you don't see it a problem because you reject the common understanding about tunnel as a virtual link, but define the so-called 4rd-tunnel. it has been admitted by your statement that 4rd tunnel is not any tunnel. my understanding here is 4rd tunnel is ACTUALLY another path section of

Re: [Softwires] I-D Action: draft-ietf-softwire-public-4over6-01.txt

Hi Authors, For section 5.3, I think 2 things should be explicitly stated. 1. hairpinning should be supported on the 4over6 concentrator 2. when 4-in-6 packets received, the inner ipv4 src ip address should be checked against outter ipv6 src ip to see if they are match. (Actually, this should be

Re: [Softwires] Comments on 4rd-u-04

Hi Remi, Thanks for the clarification. Only one response, 3. Fragments. The algorithm proposed in R-9, would have applied to generic NAT generally. Why it is specific to 4rd BR? NATs may have to remember not only destination ports but also source ports. Yes. I agree. A similar algorithm

[Softwires] Comments on 4rd-u-04

Hi, Eventually I get a chance to review this version and have some major comments and questions as below. 1. Relationship with MAP, MAP-T, MAP-E. I thought, MAP was expected to be a generic algorithm for stateless mapping IPv4 addresses to IPv6 addresses and vice versa. I thought, MAP would

Re: [Softwires] IPv4 Residual Deployment - Unified-standard proposal 4rd

Hi Remi, Secondly, -04 added NAT64+ parts. If I understood correctly, there are no additional requirements for NAT64 boxes. Well, NAT64 boxes remain what they are. Any host can use BIH to look like an IPv6-only host in the NAT64 although it has a dual stack. But the advantage of 4rd

Re: [Softwires] Checksum neutrality and L4-protocol independence

Hi Maoke, Just one point. Please see inline. i don't think MAP standard have nor should have such a limitation. A MAP-compliant device supports UDP, TCP, DCCP, SCTP today, with the same logic, and will support any emerging L4 protocol in the future, again with the same logic. requiring L4

Re: [Softwires] 4rd-addmapping - Possible independence of the IPv6 addressing plan from IPv4 prefixes

Hi Remi, Please see inline. 2011/10/21 Rémi Després despres.r...@laposte.net: The PSID is WITHIN the /60 (at its end). The IPv6 /64 prefix to be used to reach a CE contains: 1) The Rule IPv6 prefix (that of the rule whose IPv4 prefix matches the IPv4 destination) 2) The IPv4 suffix (that

Re: [Softwires] 4rd Address Mapping - version-01

Hi Remi, I found this version is more clearer and simpler thanks to those examples and diagrams. I have 3 comments here: 1. You mentioned port-less layer-4 protocol in section 6, were you refering to ICMP? IIRC, the echo request sequence can be seen as a port to some extend. But it was not

Re: [Softwires] Comments on draft-despres-softwire-4rd-addmapping-00

Hi Remi, Please see inline. 7. in example a in section 6, how come a mapping rule responding to 2 cpe ipv6 prefix length? cpe will get confused when it did forwarding. CPE prefix lengths may be different. (It is the Domain prefix length that is given in the rule.) This is key to be able

Re: [Softwires] Comments on draft-despres-softwire-4rd-addmapping-00

Got it. Thanks Remi. washam 2011/8/21 Rémi Després despres.r...@laposte.net: Hi Washam, Please see below. Le 21 août 2011 à 08:01, Washam Fan a écrit : Hi Remi, Please see inline. 7. in example a in section 6, how come a mapping rule responding to 2 cpe ipv6 prefix length? cpe

Re: [Softwires] are multiple Domain IPv6 prefixes possible?

2011/8/19 Rémi Després despres.r...@laposte.net: Le 18 août 2011 à 09:18, Washam Fan a écrit : It seems to me, when delegating CE ipv6 prefix, a longest match might be used. OK, but, again, if a realistic use case is available where longest match is indeed REQUIRED, there is no problem

Re: [Softwires] are multiple Domain IPv6 prefixes possible?

It seems to me, when delegating CE ipv6 prefix, a longest match might be used. OK, but, again, if a realistic use case is available where longest match is indeed REQUIRED, there is no problem to impose longest match. What is missing so far is this use case. can i cite Tetsuya's examples to

Re: [Softwires] are multiple Domain IPv6 prefixes possible?

Hi, It seems to me, when delegating CE ipv6 prefix, a longest match might be used. But when forwarding a IPv4 packet, a longest match is useless, because domain 4rd prefixes don't overlap. Why? Sorry, I don't follow. The domain IPv4 prefixes can overlap. if domain 4rd prefixes overlap, when

Re: [Softwires] are multiple Domain IPv6 prefixes possible?

Hi Jacni 2011/8/18 Jacni Qin ja...@jacni.com: On 8/18/2011 3:24 PM, Washam Fan wrote: Hi, It seems to me, when delegating CE ipv6 prefix, a longest match might be used. But when forwarding a IPv4 packet, a longest match is useless, because domain 4rd prefixes don't overlap. Why? Sorry

Re: [Softwires] are multiple Domain IPv6 prefixes possible?

Hi Remi 2011/8/18 Rémi Després despres.r...@laposte.net: Le 18 août 2011 à 09:18, Washam Fan a écrit : It seems to me, when delegating CE ipv6 prefix, a longest match might be used. OK, but, again, if a realistic use case is available where longest match is indeed REQUIRED

Re: [Softwires] are multiple Domain IPv6 prefixes possible?

It seems to me, when delegating CE ipv6 prefix, a longest match might be used. But when forwarding a IPv4 packet, a longest match is useless, because domain 4rd prefixes don't overlap. Thanks, washam 2011/8/17 Rémi Després despres.r...@laposte.net: Le 17 août 2011 à 03:10, Jacni Qin a écrit :

Re: [Softwires] are multiple Domain IPv6 prefixes possible?

whose domain 4rd prefix has the longest match with the the destination ipv4 address, can be selected. It is stated in section 5.1.1 and section 7 a little bit in the draft. Thanks, Tetsuya Murakami On 2011/08/14, at 5:52, Washam Fan wrote: Hi, It seems to me only one domain IPv6 prefix

Re: [Softwires] Why not use AFTR IPv6 address for the new DHCPv6 option?

for the BR configuration on CEs? Best Regards, Zhenqiang Li 2011-07-03 - Original Message - From: Washam Fan Sent: 2011-07-01 13:04:46 To: lizhenqi...@chinamobile.com CC: softwires@ietf.org Subject: Re: [Softwires] Why not use AFTR IPv6 address for the new DHCPv6 option

Re: [Softwires] Why not use AFTR IPv6 address for the new DHCPv6 option?

Hi, There was a debate between ip literal v.s. fqdn for this issue. Please search the old mail archive to check it out. If I recall correctly, a major argument would be, many ISPs prefer dns server to do load balancing over dhcp server. Thanks, washam 2011/6/30 lizhenqi...@chinamobile.com: Hi

Re: [Softwires] [v4tov6transition] Comment on draft-despres-softwire-6a44-01.txt

Hi Dong and Brian, 2010/10/16 Brian E Carpenter brian.e.carpen...@gmail.com: On 2010-10-16 15:15, Dong Zhang wrote: Hi Remi, Please see inline. ... Is the A:W-N:Z mapping created staticly? Or dynimicly? Dynamically when the 6a44-C starts operation. It then remains static until the 6a44

Re: [Softwires] [v4tov6transition] IPv6 VPNs configured over 1280 MTU tunnels

, -Original Message- From: Washam Fan [mailto:washam@gmail.com] Sent: Monday, October 11, 2010 10:48 PM To: Templin, Fred L Cc: Rémi Després; Softwires; v4tov6transit...@ietf.org Subject: Re: [v4tov6transition] IPv6 VPNs configured over 1280 MTU tunnels Hi Fred, I might see your points

Re: [Softwires] DHCPv6 AFTR name option is needed

Hi Hemant, As I know, since 6rd BRs are stateless, so you can configure an anycast address for load balancing stuff. Thanks, washam 2010/10/13 Hemant Singh (shemant) shem...@cisco.com: A general question.  If 6rd could become an RFC in RFC 5969 with no mention of FQDN for the BR, what is so

Re: [Softwires] [v4tov6transition] IPv6 VPNs configured over 1280 MTU tunnels

...@free.fr] Sent: Monday, October 11, 2010 10:05 AM To: Templin, Fred L Cc: Washam Fan; Softwires; v4tov6transit...@ietf.org Subject: Re: [v4tov6transition] IPv6 VPNs configured over 1280 MTU tunnels Le 11 oct. 2010 à 18:42, Templin, Fred L a écrit : ... Actually, the 6a44

Re: [Softwires] [v4tov6transition] IPv6 VPNs configured over 1280 MTU tunnels

, for the latter, black hole might occur. I see problems here. Thanks, washam 2010/10/12 Templin, Fred L fred.l.temp...@boeing.com: Hi Washam, -Original Message- From: Washam Fan [mailto:washam@gmail.com] Sent: Monday, October 11, 2010 7:38 PM To: Templin, Fred L Cc: Rémi Després

Re: [Softwires] [v4tov6transition] IPv6 VPNs configured over 1280 MTU tunnels

Hi, 2010/10/9 Templin, Fred L fred.l.temp...@boeing.com: End systems in end user networks that connect to the IPv6 Internet will likely want to configure IPv6 VPNs, e.g., so that they can securely connect to their home office networks. Those VPN links must present a 1280 minimum MTU to upper

[Softwires] comments on draft-despres-softwire-6a44-00

Hi, Thanks for your work on this issue. I have some comments: 1. From 6a44 address format, the 6a44 client can only act as a IPv6 host but not IPv6 node which could attach to a IPv6 LAN. I think this is different from draft-lee-softwire-6rd-udp. 2. For host to host 6a44 communication, I think

Re: [Softwires] comments on draft-carpenter-softwire-sample-00

Teredo does precisely that. But, it relies on relays that may or may not work for you. I'm not sure which is the best for where you are located in China, but here's a list of services that will terminate the other end of the Tunnel for you beyond your SP:

Re: [Softwires] comments on draft-carpenter-softwire-sample-00

Teredo does precisely that. But, it relies on relays that may or may not work for you. I'm not sure which is the best for where you are located in China, but here's a list of services that will terminate the other end of the Tunnel for you beyond your SP: