Re: [Softwires] [v4tov6transition] ISP support of Native IPv6 across NAT44 CPEs -Proposed 6a44 Specification
Le 7 oct. 2010 à 21:28, Ole Troan a écrit : ... issues I have with host tunneling: - how to communicate with native IPv6 nodes on the same network? The 6a44-S decapsulates IPv6 packets coming from a 6a44 host and, if not destined to another 6a44 host of its network, forwards them in IPv6, in this case on the same network. - how to communicate to another 6a44 host on a different link in the same home? 6a44 is only for hosts on a LAN behind a NAT44 attached to a 6a44-capable ISP network. If the LAN has several bridged links, it does apply. Links that are behind extra NATs in the site are out of scope. As I said to Olivier Vautrin in a previous mail on this thread, these extra NATs should be configured so that hosts behind them never receive 6a44 IPv6-Address-Indication messages. (e;g. with the 6a44 well-known port bound to an unassigned internal address. This point isn't in the draft yet but, if co-authors agree, should be in the next version. - do you need non-congruent topology multi-homing policy? http://tools.ietf.org/html/draft-troan-multihoming-without-nat66-01 how do you distribute that policy when you don't have a on-link router? Not sure to understand the question. The answer should be NO: 6a44 only needs classical topologies. - a general unease that now every host is supposed to have a VPN connection? how do I configure my own firewall and other network border policy? If the NAT binds the 6a44 well-known port to an unassigned internal address, no host will be able to receive a 6a44 IPv6 address. Besides, a firewall could filter all packets having this port, source or destination. how much would a new CPE cost the customer? 80USD? that's only 5 pints of beer (if bought in Norway.) I really liked the dongle idea by the way. perhaps with a L2TP LAC. The dongle idea of 6rd-UDP, if without a stateful NAT66 in the dongle, needs an assigned /16 to the function. (The /64 subnet prefix has to contain the site IPv4 address plus the port of the tunnel). This is in general not realistic. Now, if there is a NAT66 in the dongle, it can work with a 6a44 external address. I hope it helps to understand that 6a44 isn't just one more design for the pleasure to make one, but a pragmatic solution to a real problem, specified after an in depth study. Cheers, RD cheers, Ole ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] [v4tov6transition] ISP support of Native IPv6 across NAT44 CPEs -Proposed 6a44 Specification
Remi, ... issues I have with host tunneling: - how to communicate with native IPv6 nodes on the same network? The 6a44-S decapsulates IPv6 packets coming from a 6a44 host and, if not destined to another 6a44 host of its network, forwards them in IPv6, in this case on the same network. I was thinking of another native IPv6 node in the same home. as 6a44 doesn't enable IPv6 support in the home network I don't see how this would work. - how to communicate to another 6a44 host on a different link in the same home? 6a44 is only for hosts on a LAN behind a NAT44 attached to a 6a44-capable ISP network. If the LAN has several bridged links, it does apply. Links that are behind extra NATs in the site are out of scope. As I said to Olivier Vautrin in a previous mail on this thread, these extra NATs should be configured so that hosts behind them never receive 6a44 IPv6-Address-Indication messages. (e;g. with the 6a44 well-known port bound to an unassigned internal address. This point isn't in the draft yet but, if co-authors agree, should be in the next version. I was thinking of the case of a routed home. no additional NATS. I don't see how the mechanism would work across routers. since you don't get a prefix for the site. the homegate/homenet WG proposal was rejected by the IESG, but it would have been useful to have the home network architecture document as background for this discussion... - do you need non-congruent topology multi-homing policy? http://tools.ietf.org/html/draft-troan-multihoming-without-nat66-01 how do you distribute that policy when you don't have a on-link router? Not sure to understand the question. The answer should be NO: 6a44 only needs classical topologies. if a 6a44 node is multi-homed to 3 networks, the 6a44 network the IPV4 network and possibly a native IPv6 network (e.g. ULA in the home), would you need to distribute SAS/NH/DNS policy? - a general unease that now every host is supposed to have a VPN connection? how do I configure my own firewall and other network border policy? If the NAT binds the 6a44 well-known port to an unassigned internal address, no host will be able to receive a 6a44 IPv6 address. Besides, a firewall could filter all packets having this port, source or destination. that doesn't give me ability to filter on IPv6 applications on the network border... not specific to 6a44, this is just an artifact of host tunneling. how much would a new CPE cost the customer? 80USD? that's only 5 pints of beer (if bought in Norway.) I really liked the dongle idea by the way. perhaps with a L2TP LAC. The dongle idea of 6rd-UDP, if without a stateful NAT66 in the dongle, needs an assigned /16 to the function. (The /64 subnet prefix has to contain the site IPv4 address plus the port of the tunnel). This is in general not realistic. my suggestion is to use L2TP, which has none of those particular shortcomings. Now, if there is a NAT66 in the dongle, it can work with a 6a44 external address. I hope it helps to understand that 6a44 isn't just one more design for the pleasure to make one, but a pragmatic solution to a real problem, specified after an in depth study. is the in-depth study available? cheers, Ole ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] DHCPv6 AFTR name option is needed
Hello Tomek, Thanks for your reply. The redundancy use case described by Med is the applicability scenario we have in mind too, for the ATFR name option. I understand the doubts raised, in defining two options to configure similar parameters, but from a Service Provider's point of view we believe these to options fit different use cases. In my opinion one way to address this point and having both of them in the draft could be either saying that only one of the two options can be present in the DHCP message or to specify a priority that implies what should be the behavior in case both parameters are present. In addition allowing specifying IP add or Name for a tunnel configuration is not a new concept, for example also in case of L2TP tunnel there was the possibility to specify either the tunnel endpoint name or the IP address. Regards, Roberta From: mohamed.boucad...@orange-ftgroup.com [mailto:mohamed.boucad...@orange-ftgroup.com] Sent: venerdì 8 ottobre 2010 7.31 To: Tomasz Mrugalski; Softwires WG Cc: draft-ietf-softwire-ds-lite-tunnel-opt...@tools.ietf.org; Softwire Chairs; Ullio Mario; Jari Arkko; Ralph Droms; Maglione Roberta Subject: RE: [Softwires] DHCPv6 AFTR name option is needed Dear Tomek, Thank you for this clarification. Providing the IP address in the option is not flexible enough and especially it may not be recommended to achieve load balancing. Otherwise the DHCPv6 server should act as a load balancer, which is not currently our preference. To illustrate more the usage with the domain name option: The scenario I mentioned (is similar to what currently done in some VoIP networks for distributing customers among SBC nodes or P-CSCFs): you provide a generic FQDN of the AFTR by the DHCP server together with a suffix in the dns serach list option. When the B4 receives these two options, it will form a the FQDN to use to resolve its AFTR. Then a query is sent to the DNS system (it can be dedicated to the service), and based on the load considerations, the requesting client is redirected to the appropriate AFTR nodes (i.e., an IP address is returned). With the sole IP address option we can not have such engineering flexibility for the provisioning of the AFTR. Having the two options allow for more flexibility for the engineering. IMHO, the IETF should not impose engineering choice to SPs. It will be up to each service provider to decide whether an IP address or a FQDN is more convenient in his deployment context. Hope this clarifies our concern. Cheers, Med De : Tomasz Mrugalski [mailto:tomasz.mrugal...@gmail.com] Envoyé : vendredi 8 octobre 2010 02:00 À : Softwires WG Cc : BOUCADAIR Mohamed NCPI/NAD/TIP; draft-ietf-softwire-ds-lite-tunnel-opt...@tools.ietf.org; Softwire Chairs; Ullio Mario; Jari Arkko; Ralph Droms; Maglione Roberta Objet : Re: [Softwires] DHCPv6 AFTR name option is needed Roberta, Mohamed, AFTR name option was removed as a result of a concerns raised by Jari Arkko and Ralph Droms during IESG review. They were very clear that defining two options to configure the same parameter is not acceptable. Regarding scenario mentioned by Mohamed, since you are already differentiating between different locations (as I understand in your scenario different locations provide different DNS addresses that resolve the same AFTR FQDN to different addresses, right?), you may do this explicitly and provide different AFTR addresses. Would that solve the problem? Hope that helps. Tomek On Thu, Oct 7, 2010 at 4:58 PM, Maglione Roberta roberta.magli...@telecomitalia.itmailto:roberta.magli...@telecomitalia.it wrote: Hello All, I fully agree with Med, both AFTR IP address and AFTR name options are needed, in order to be able to handle different scenarios. We really would like to see both of them back in the draft. Best regards, Roberta -Original Message- From: softwires-boun...@ietf.orgmailto:softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.orgmailto:softwires-boun...@ietf.org] On Behalf Of mohamed.boucad...@orange-ftgroup.commailto:mohamed.boucad...@orange-ftgroup.com Sent: giovedì 7 ottobre 2010 10.07 To: draft-ietf-softwire-ds-lite-tunnel-opt...@tools.ietf.orgmailto:draft-ietf-softwire-ds-lite-tunnel-opt...@tools.ietf.org; Softwire Chairs Cc: softwires@ietf.orgmailto:softwires@ietf.org Subject: [Softwires] DHCPv6 AFTR name option is needed Dear authors, chairs, We are surprised to see the AFTR name option being removed from the latest version of this draft: http://tools.ietf.org/rfcdiff?url2=draft-ietf-softwire-ds-lite-tunnel-option-05.txt Is there any reason why this option has been removed? We would like to see this option back to the draft and that *** both *** the AFTR IP address and the name options are defined. FWIW, one of the deployment use cases we are considering is the distribution of the DS-Lite serviced customers among several (geo
Re: [Softwires] DHCPv6 AFTR name option is needed
Hi Yiu, all, If there is a real issue with defining two DHCPv6 options (which I don't see), an alternative would be to define one option with a sub-code field. This field indicates whether the option carries an IP address or a name option. Cheers, Med De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de Yiu L. Lee Envoyé : vendredi 8 octobre 2010 16:55 À : Tomasz Mrugalski; Softwires WG Cc : draft-ietf-softwire-ds-lite-tunnel-opt...@tools.ietf.org; Softwire Chairs; Ullio Mario Objet : Re: [Softwires] DHCPv6 AFTR name option is needed How about define a new option just for FQDN? Will this address the IESG's concern? On 10/7/10 11:24 PM, Tomasz Mrugalski tomasz.mrugal...@gmail.com wrote: Roberta, Mohamed, AFTR name option was removed as a result of a concerns raised by Jari Arkko and Ralph Droms during IESG review. They were very clear that defining two options to configure the same parameter is not acceptable. Regarding scenario mentioned by Mohamed, since you are already differentiating between different locations (as I understand in your scenario different locations provide different DNS addresses that resolve the same AFTR FQDN to different addresses, right?), you may do this explicitly and provide different AFTR addresses. Would that solve the problem? Hope that helps. Tomek On Thu, Oct 7, 2010 at 11:58 AM, Maglione Roberta roberta.magli...@telecomitalia.it wrote: Hello All, I fully agree with Med, both AFTR IP address and AFTR name options are needed, in order to be able to handle different scenarios. We really would like to see both of them back in the draft. Best regards, Roberta -Original Message- From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] On Behalf Of mohamed.boucad...@orange-ftgroup.com Sent: giovedì 7 ottobre 2010 10.07 To: draft-ietf-softwire-ds-lite-tunnel-opt...@tools.ietf.org; Softwire Chairs Cc: softwires@ietf.org Subject: [Softwires] DHCPv6 AFTR name option is needed Dear authors, chairs, We are surprised to see the AFTR name option being removed from the latest version of this draft: http://tools.ietf.org/rfcdiff?url2=draft-ietf-softwire-ds-lite-tunnel-option-05.txt Is there any reason why this option has been removed? We would like to see this option back to the draft and that *** both *** the AFTR IP address and the name options are defined. FWIW, one of the deployment use cases we are considering is the distribution of the DS-Lite serviced customers among several (geo distributed) AFTRs by combining the search domain name dhcpv6 option (Code 24) and a generic FQDN conveyed in the AFTR name option. This would allow for a more controlled load distribution among deployed AFTRs. Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de internet-dra...@ietf.org Envoyé : lundi 27 septembre 2010 21:30 À : i-d-annou...@ietf.org Cc : softwires@ietf.org Objet : [Softwires] I-D Action:draft-ietf-softwire-ds-lite-tunnel-option-05.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Softwires Working Group of the IETF. Title : Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for Dual- Stack Lite Author(s) : D. Hankins, T. Mrugalski Filename: draft-ietf-softwire-ds-lite-tunnel-option-05.txt Pages : 6 Date: 2010-09-27 This document specifies single DHCPv6 option which is meant to be used by a Dual-Stack Lite client (Basic Bridging BroadBand element, B4) to discover its Address Family Transition Router (AFTR) address. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-softwire-ds-lite-tunnel-option-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. * This message and any attachments (the message) are confidential and intended solely for the addressees. Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration. France Telecom Group shall not be liable for the message if altered, changed or falsified. If you are not the intended addressee of this message, please cancel it immediately and inform the sender. ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore
[Softwires] IPv6 VPNs configured over 1280 MTU tunnels
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 layers, but if they traverse a link in the path with a too-small MTU then the end system will see an MTU underrun and will need to use IPv6 fragmentation. An IPv6-in-IPv4 tunnel with a fixed static 1280 MTU is an example of a link in the path that could cause such an MTU underrun for end system VPN links. So, should we be concerned that tunnels with a fixed 1280 MTU would make life difficult for the common operational practice of end systems using VPNs? Thanks - Fred fred.l.temp...@boeing.com -Original Message- From: v4tov6transition-boun...@ietf.org [mailto:v4tov6transition-boun...@ietf.org] On Behalf Of Templin, Fred L Sent: Friday, October 08, 2010 7:52 AM To: Yiu L. Lee; Brian E Carpenter; Ole Troan Cc: Softwires; v4tov6transit...@ietf.org Subject: Re: [v4tov6transition] [Softwires] ISP support of NativeIPv6across NAT44 CPEs -Proposed 6a44 Specification CPE. This double tunneling tech seems scary. More to this point about double-tunneling, how were folks thinking that IPv6 VPNs would be run over a 1280 MTU IPv6-in-IPv4 tunnel? That is double-tunneling, and seems like it would be a quite common case, but the MTU seems deficient. Should it use IPv6 fragmentation? Fred fred.l.temp...@boeing.com ___ v4tov6transition mailing list v4tov6transit...@ietf.org https://www.ietf.org/mailman/listinfo/v4tov6transition ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] [v4tov6transition] ISP support of Native IPv6 across NAT44 CPEs -Proposed 6a44 Specification
Hi Brian, I think this is all relative. I discussed internally about software download. Their answer to me is BIG NO. Reason is SP must run QA tests for every possible OS/patches combination. Worst is we need to redo this again when a new patch/upgrade is released. This is far costly than you can imagine (way more than the $80 new CPE). In the end, I would vote for the dongle based over host based anytime. Is dongle more viable option than new CPE? I think this is the real debate. Cheers, Yiu On 10/7/10 6:47 PM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: Ole, I really liked the dongle idea by the way. I'm not convinced. If people are willing to buy such a thing, and if you are correct about $80 IPv6-enabled CPEs, I think the latter will win. So the real question for me is whether a $0 dollar download will beat an $80 purchase. Predicting customer bahaviour is hard. IMHO, we can put both on the market and see what happens. Regards Brian On 2010-10-08 08:28, Ole Troan wrote: Remi, [...] ISPs that aren't concerned with what their customer would like to have will eventually face competition. we are in complete agreement of the end goal. it is just how we get there... A key point is that supporting 6a44 is very inexpensive compared to other supports they have to envisage. Yet, as Yiu says, this still depends on which hosts will support 6a44. My personal hope is that we will soon see trials, including with mobile phones. issues I have with host tunneling: - how to communicate with native IPv6 nodes on the same network? - how to communicate to another 6a44 host on a different link in the same home? - do you need non-congruent topology multi-homing policy? http://tools.ietf.org/html/draft-troan-multihoming-without-nat66-01 how do you distribute that policy when you don't have a on-link router? - a general unease that now every host is supposed to have a VPN connection? how do I configure my own firewall and other network border policy? how much would a new CPE cost the customer? 80USD? that's only 5 pints of beer (if bought in Norway.) I really liked the dongle idea by the way. perhaps with a L2TP LAC. cheers, Ole ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] [v4tov6transition] ISP support of Native IPv6across NAT44 CPEs -Proposed 6a44 Specification
Yiu, -Original Message- From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] On Behalf Of Yiu L. Lee Sent: Friday, October 08, 2010 11:36 AM To: Brian E Carpenter; Ole Troan Cc: Softwires; v4tov6transit...@ietf.org Subject: Re: [Softwires] [v4tov6transition] ISP support of Native IPv6across NAT44 CPEs -Proposed 6a44 Specification Hi Brian, I think this is all relative. I discussed internally about software download. Their answer to me is BIG NO. Reason is SP must run QA tests for every possible OS/patches combination. Worst is we need to redo this again when a new patch/upgrade is released. This is far costly than you can imagine (way more than the $80 new CPE). In the end, I would vote for the dongle based over host based anytime. Is dongle more viable option than new CPE? I think this is the real debate. But then the dongle/CPE becomes the ball-and-chain that locks the customer into the SP's PA addressing scheme... Fred fred.l.temp...@boeing.com Cheers, Yiu On 10/7/10 6:47 PM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: Ole, I really liked the dongle idea by the way. I'm not convinced. If people are willing to buy such a thing, and if you are correct about $80 IPv6-enabled CPEs, I think the latter will win. So the real question for me is whether a $0 dollar download will beat an $80 purchase. Predicting customer bahaviour is hard. IMHO, we can put both on the market and see what happens. Regards Brian On 2010-10-08 08:28, Ole Troan wrote: Remi, [...] ISPs that aren't concerned with what their customer would like to have will eventually face competition. we are in complete agreement of the end goal. it is just how we get there... A key point is that supporting 6a44 is very inexpensive compared to other supports they have to envisage. Yet, as Yiu says, this still depends on which hosts will support 6a44. My personal hope is that we will soon see trials, including with mobile phones. issues I have with host tunneling: - how to communicate with native IPv6 nodes on the same network? - how to communicate to another 6a44 host on a different link in the same home? - do you need non-congruent topology multi-homing policy? http://tools.ietf.org/html/draft-troan-multihoming-without-nat66-01 how do you distribute that policy when you don't have a on-link router? - a general unease that now every host is supposed to have a VPN connection? how do I configure my own firewall and other network border policy? how much would a new CPE cost the customer? 80USD? that's only 5 pints of beer (if bought in Norway.) I really liked the dongle idea by the way. perhaps with a L2TP LAC. cheers, Ole ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] [v4tov6transition] ISP support of Native IPv6acrossNAT44 CPEs -Proposed 6a44 Specification
HI Yiu, -Original Message- From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] On Behalf Of Yiu L. Lee Sent: Friday, October 08, 2010 11:58 AM To: Templin, Fred L; Brian E Carpenter; Ole Troan Cc: Softwires; v4tov6transit...@ietf.org Subject: Re: [Softwires] [v4tov6transition] ISP support of Native IPv6acrossNAT44 CPEs -Proposed 6a44 Specification Hi Fred, But then the dongle/CPE becomes the ball-and-chain that locks the customer into the SP's PA addressing scheme... This is what most ISPs offer to residential and small home office users. So this is no worse. Understood that it is PA in the underlay network space, and that is all well and good. But, PI in the overlay network space (instead of PA) is an option that should be made available to customers. Thanks - Fred fred.l.temp...@boeing.com Cheers, Yiu ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] [v4tov6transition] ISP support of Native IPv6acrossNAT44 CPEs -Proposed 6a44 Specification
Understood that it is PA in the underlay network space, and that is all well and good. But, PI in the overlay network space (instead of PA) is an option that should be made available to customers. Maybe if there is enough demand. Cheers, Yiu ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
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 layers, but if they traverse a link in the path with a too-small MTU then the end system will see an MTU underrun and will need to use IPv6 fragmentation. An IPv6-in-IPv4 tunnel with a fixed static 1280 MTU is I assume you were refering 6a44. The reason why 6a44 restricts 1280 MTU is IPv6 PMTU performance is not reliable practically, per Remi's reponse to me. If PMTU could (and I think it should) perform well, 6a44 would permit more larger MTU. For this bullet in sec5, draft-despres-softwire-6a44-00 o 6a44 Server functions refuse packets received from their IPv6 pseudo interfaces if their sizes exceed 1280 octets, with ICMPv6 Packet Too Big messages returned to sources as required by [RFC2460].) I think it could only apply to the case where the received IPv6 packets forwarded to the external domain. In the case the 6a44 server does the hairpinning, the 6a44 server would refuse packets whose size exceed (IPv4 MTU - 28) octets, with ptb ICMPv6 msg. Thanks, washam an example of a link in the path that could cause such an MTU underrun for end system VPN links. So, should we be concerned that tunnels with a fixed 1280 MTU would make life difficult for the common operational practice of end systems using VPNs? Thanks - Fred fred.l.temp...@boeing.com -Original Message- From: v4tov6transition-boun...@ietf.org [mailto:v4tov6transition-boun...@ietf.org] On Behalf Of Templin, Fred L Sent: Friday, October 08, 2010 7:52 AM To: Yiu L. Lee; Brian E Carpenter; Ole Troan Cc: Softwires; v4tov6transit...@ietf.org Subject: Re: [v4tov6transition] [Softwires] ISP support of NativeIPv6across NAT44 CPEs -Proposed 6a44 Specification CPE. This double tunneling tech seems scary. More to this point about double-tunneling, how were folks thinking that IPv6 VPNs would be run over a 1280 MTU IPv6-in-IPv4 tunnel? That is double-tunneling, and seems like it would be a quite common case, but the MTU seems deficient. Should it use IPv6 fragmentation? Fred fred.l.temp...@boeing.com ___ v4tov6transition mailing list v4tov6transit...@ietf.org https://www.ietf.org/mailman/listinfo/v4tov6transition ___ v4tov6transition mailing list v4tov6transit...@ietf.org https://www.ietf.org/mailman/listinfo/v4tov6transition ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
