At 15:17 04/03/2011, Xiangsong Cui wrote:
Dear JFC,
Many thanks for your detailed explanation!
But I still don't understand that, in my understanding, network
prefix is a part of IPv6 network address, so the network prefix
translation is actually a "partial" network address translation, right?
Dear Xiangsong,
on the IETF side, i.e. managing the inside internet you are right
(128 bits addresses). On the user side things are flexible. This only
beg you to differentiate the IPv6 inside Internet protocol from the
IPv6 network addressing scheme.
Actually an IPv6 address is made of two parts:
- an IPv6 network address (header) which is allocated by the ISP:
this is the actual IPv6 address.
- a payload to deliver a user internal network address of any
technology at that IP address. The IETF calls it IID. IUsers call it
IDv6 to differentiate it from other IIDs from other technologies or
protocol environment (starting with IPv4), adressing plans, existing
ones or future ones to come.
NPTv6 inserts the correct IPv6 header ahead of IDv6 so the whole
address can cross the Internet in using the IPv6 protocol and reach
the other end. There, the IPv6 header (address) may be removed if the
local network is only using its IDv6. This for exemple permits a user
system to be connected to the internet through different ISPs or
different channels: same IDv6, different IPv6.
Having kept the IPv6 as a single 128 bits address is the reason why
IPv6 did not take off until now. There is no particular interest to
the IUser to invest in a rigid application to application IPv6 dump
proposition. On the countrary, there is a big IUser interest in
IDv6, that can be also used easily under IPv4 (for example in using
IDv6s under alphadigital DN label form) and other technologies and
"externets" (what the DNS identfies as a class and the addressing was
unable to support).
However, please keep in mind that this "big" interest is still
numerically reduced in people because the IUse community is only
emerging. Also the IUI has been identified as not being part as such
of the IETF scope (IAB/IESG), so we have everything to build to
support a new network stratum including the presentation layer but
also other new layers (extended network model) able to dialog with
other technologies. IESG qualified this as "research", this is true
but an IUI architecture like InterPlus (Pluggable layers on the User
side) may qualify as an "emergency" solution for some existing global needs.
jfc
Best Regards
Xiangsong
----- ÔÓʼþ -----
·¢¼þÈË: JFC Morfin <[email protected]>
ÈÕÆÚ: ÐÇÆÚÎå, ÈýÔÂ 4ÈÕ, 2011 ÏÂÎç6:12
Ö÷Ìâ: Re: [nat66] Fwd: New Version Notification - draft-mrw-nat66-08.txt
ÊÕ¼þÈË: Xiangsong Cui <[email protected]>, 'Fred Baker'
<[email protected]>, 'NAT66 HappyFunBall' <[email protected]>
> 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
