[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] NAT-PT and other approaches to IPv6 adoption
- To: Routing Research Group <rrg@psg.com>
- Subject: Re: [RRG] NAT-PT and other approaches to IPv6 adoption
- From: Brian E Carpenter <brian.e.carpenter@gmail.com>
- Date: Wed, 11 Jun 2008 11:35:03 +1200
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; b=lJRfGwkO7Y5WWcLgxymOAmb2DZgICcJ20Ho9wmlTeKGEZ5urf3/2nPbWMuFfbRs6aX zdX1/HjIhzHZLckvg4PXzefWWwb0/CtrH4Ko01wFWmmwy58FLWQcmL/NNnFCw9SFwO/t x5OHUkwqnPRG00pFty8cIfS3nXPZ/DA41ipUE=
- In-reply-to: <484E8181.30403@firstpr.com.au>
- Organization: University of Auckland
- References: <484E8181.30403@firstpr.com.au>
- User-agent: Thunderbird 2.0.0.6 (Windows/20070728)
> NAT-PT is one approach to enabling an IPv6-only host to communicate
> with the IPv4 Internet. What other approaches are there?
1. IPv4-over-IPv6 tunnels. That assumes that the host with IPv6-only
connectivity is a dual stack host, which applies to about 100%
of IPv6 hosts today. Current work in IETF SOFTWIRE WG.
2. Application level proxies, for the major applications. This
is running code for SMTP, HTTP and other cases.
For many consumer scenarios, this is sufficient.
3. Translation that's better than NAT-PT. See
draft-ietf-v6ops-nat64-pb-statement-req and
draft-bagnulo-behave-nat64 for the latest IETF work on this.
The RRG shouldn't be worrying about this area IMHO.
Brian
--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg