This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/ipv6-wg@ripe.net/
[ipv6-wg] Implications of NAT/NAT64 and similar
- Previous message (by thread): [ipv6-wg] Implications of NAT/NAT64 and similar
- Next message (by thread): [ipv6-wg] IPv6 only as default for next meeting
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
๐Dan Wing
dwing at cisco.com
Mon May 18 18:57:08 CEST 2015
On 17-May-2015 09:52 am, Benedikt Stockebrand <bs at stepladder-it.com> wrote: > > Hi Dan and list, > > ๐Dan Wing <dwing at cisco.com> writes: > >> On 15-May-2015 02:25 am, Benedikt Stockebrand <bs at stepladder-it.com> wrote: >>> [Implications of NAT64] >> >> To avoid some of that, they can go IPv6-only, including their servers >> and all peers they communicate with, then there doesn't need to be >> NAT64 for their traffic. But even IPv6-only they will need firewall >> traversal support, as firewalls by default will block unsolicited >> incoming traffic (RFC6092). > > I'm not sure if I get you correctly, but: Do you mean IPv6 only, or > dual-stacked servers (so whatever a client connects with works without > translation)? Go IPv6-only. If servers run IPv4 there will be a NAT on path, necessitating the NAT traversal support in the client. But IPv6-only reduces the market to only those homes/businesses with IPv6. Short version of what I'm saying: there is no way to avoid NAT translation support in the client. -d
- Previous message (by thread): [ipv6-wg] Implications of NAT/NAT64 and similar
- Next message (by thread): [ipv6-wg] IPv6 only as default for next meeting
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ ipv6-wg Archives ]