> 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.
It seems to me that you are taking IPv6 address as "ID + locator", prefix is
the location and IID is the Identifier.
However, the traditional IPv6 address is "ID&locator", the IPv6 address
provides not only the location but also the Identifier.
>
> 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).
I'm not sure, but I don't think IDv6 would accelerate IPv6 development.
In my impression, the slow IPv6 transition is because there are too many
NAT64 NATs, so the participants have no strong motivation to develop IPv6.
Now your bring NPT66 (another manner of NAT, as you said "an IPv6 network
address (header) which is allocated by the ISP: this is the actual IPv6
address", this box is an actual address translation device) or splitting
IPv6 ("ID&Locator" => "ID + Locator"), are they really beneficial to pure
IPv6?
Thanks and regards,
Xiangsong
>
> 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
