Dear Xiangsong Cui,
The change in terminology from NAT66 to NPTv6 is the correct
acknowledgment of your remark. IDNA2008 served as a first example of
the way the Internet technology is able to support a very large
diversity in uncoupling the necessary stability, robustness,
simplicity of the inside network itself and the diversity, versality
and extremely large size of the outside usage. This uncoupling
necessitates an Internet Use Interface (IUI) between the inside
network and outside users. This is provided by IDNA2008 in naming,
this is provided by NPTv6 in numbering. This calls for the IUI to be
installed at the ISP or preferably on the userside.
Now, what is of interest and was discussed through my appeals to IESG
and IAB and their response last year irt. naming [but actually
uncoupling and the acknowledgment of the principle of subsidiarity in
the Internet architecturer in addidition to adaptation ability
(principle of permanent change, RFC 1958) and simplicity (RFC 3439)],
is that the IUI is also seen from the user side. This IUI's target is
to provude stability, mobility, specificity to the people centric
digital ecosystem experience: this is not limited to interfacing the
Internet and even to the Internet technology. In that perspective it
becomes an Intelligent User Interface, abiding by the fundamental
Internet principle of a dump network and intelligent fringes.
On the naming side, the equivalent to the NPT is the ML-DNS I work
on, which is to accept any language orthotypography on an exqual
footing and any naming or addressing plan (classes), while respecting
and protecting IDNA2008 on the inside Internet side. In the NPTv6
case the user's IDv6 (i.e. the IID) is protected and can be used as
encapsualted in any kind of header, starting with the IPv6 prefix,
but also a domain name, or another technology address system, or even
a different Internet addressing plans.
This means that for the emerging IUse community (Intelligent use of
the world digital ecosystem) IDv6 can be used right now by its own
right, even under IPv4 and provide by its IUse documentation a strong
incentive to switch to IPv6. Another interesting advantage for
small/medium users is that the IPSec support can be used at smart
plugs at the fringes of personal domain zones throughout the network.
Best
jfc
At 08:53 04/03/2011, Xiangsong Cui wrote:
Hi Fred,
I haven't read this draft, in fact, I'm reading RFC3002.
In section 4.3.4, it reads,
It was recommended that an effort be made to eliminate any
requirement for NAT in an IPv6 Internet. The IAB believes that the
IPv6 address space is large enough to preclude any requirement for
private address allocation [55] or address translation due to address
space shortage [15]. Therefore, accomplishing this should primarily
require installing and enforcing proper address allocation policy on
registry and service providers. It was recommended to establish
policies requiring service providers to allocate a sufficient
quantity of global addresses for a sites use. The feeling was that
NAT should be easily eliminated provided efficient strategies are
defined to address renumbering [17,62] and mobility [37] issues.
My questions here are,
Is the requirement for NAT in IPv6 Internet avoidless?
Cann't we (service provider) find appropriate policy or strategies to
address this problem?
Or the Internet situation has changed?
Thanks!
Xiangsong
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf Of
> Fred Baker
> Sent: Tuesday, March 01, 2011 6:39 AM
> To: NAT66 HappyFunBall
> Subject: [nat66] Fwd: New Version Notification - draft-mrw-nat66-08.txt
>
>
>
> Begin forwarded message:
>
> > From: [email protected]
> > Date: February 28, 2011 2:30:03 PM PST
> > To: [email protected], [email protected],
> [email protected], [email protected]
> > Subject: New Version Notification - draft-mrw-nat66-08.txt
> >
> > New version (-08) has been submitted for draft-mrw-nat66-08.txt.
> > http://www.ietf.org/internet-drafts/draft-mrw-nat66-08.txt
> >
> >
> > Diff from previous version:
> > http://tools.ietf.org/rfcdiff?url2=draft-mrw-nat66-08
> >
> > IETF Secretariat.
>
> _______________________________________________
> nat66 mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/nat66
_______________________________________________
nat66 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nat66
_______________________________________________
nat66 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nat66
