Re: [Int-area] IETF80 questions regarding "On demand IPv4 address provisioning in Dual-Stack PPP deployment" - Topic for WG?

[<[e-mail]>]

> -----Ursprüngliche Nachricht-----
> Von: Dan Wing [mailto:[e-mail]]
> Gesendet: Dienstag, 21. Juni 2011 23:55
> An: Fleischhauer, Karsten; [e-mail]
> Betreff: RE: [Int-area] IETF80 questions regarding "On demand
> IPv4 address provisioning in Dual-Stack PPP deployment" -
> Topic for WG?
>
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
> > Sent: Saturday, June 18, 2011 10:17 AM
> > To: [e-mail]; [e-mail]
> > Subject: AW: [Int-area] IETF80 questions regarding "On demand IPv4
> > address provisioning in Dual-Stack PPP deployment" - Topic for WG?
> >
> >
> > Dear Dan,
> >
> > see my comments inline
> >
> > Best
> >
> > KARSTEN
> >
> > > -----Ursprüngliche Nachricht-----
> > > Von: Dan Wing [mailto:[e-mail]]
> > > Gesendet: Samstag, 18. Juni 2011 02:29
> > > An: Fleischhauer, Karsten; [e-mail]
> > > Betreff: RE: [Int-area] IETF80 questions regarding "On demand
> > > IPv4 address provisioning in Dual-Stack PPP deployment" -
> > > Topic for WG?
> > >
> > > This technique causes a round-trip delay when an IPv4
> > > application starts up, due to the on-demand acquisition of an IPv4
> > address.
> > The situation in many cases today is, that when "an IPv4 application
> > starts up"
> > the whole PPP session incl. IPCP has to be established.
> > In the ID scenario just IPCP has to be established, so I see not a
> > disadvantage.
> > Nevertheless this round-trip issue is only valid for the
> first packet
> > of
> > a "Dual-Stack cycle".
> >
> > > This technique is useful in environments where there is no IPv4
> > address sharing
> > > (that is, with publicly-routable IPv4 addresses).
> > I think it is also useful in a Home Network scenario with
> an routed HG
> > and NAT44@HG.
> >
> > > This technique is useful when not all of
> > > the subscribers are needing IPv4 addresses (e.g., they are
> > > not connected to the Internet [powered off], or they are running
> > applications
> > > that only need  to use IPv6).
> > Ack. And we will pushing the usage of IPv6 to support this scenario.
> >
> > > This technique requires one publicly-routable
> > > IPv4 address for every IPv4 host that has an active IPv4 session
> > (which
> > > seems to have limited usefulness, considering the world
> has exhausted
> > its
> > > IPv4 address space).
> > I think this will work also in a Home Network scenario with
> an routed
> > HG and NAT44@HG.
> >
> > > This technique requires changing the host's IPv4 stack.
> > This is only valid for the PPP endpoint.
> > Our focus is the Home Network scenario with an routed HG
> and NAT44@HG.
> > The PPP endpoint is the HG. So just the HG and BNG/BRAS need to be
> > changed.
> >
> > > IPv4 address sharing (with NAPT or with an A+P technique)
> avoids that
> > > round-trip delay, and without changing the host's IPv4 stack.
> >
> > As already mentioned above the round-trip issue is only
> valid for the
> > first packet of
> > a "Dual-Stack cycle". A CGN scenario would cause an
> additional round-
> > trip delay
> > For each IPv4 packet (NAT 44 processing within the carrier network +
> > Packet forwarding via the CGN which will increase the number of
> > hops/links).
>
> How is that "an additional round trip" delay??
>
> Maybe you could share a network diagram or a message flow diagram
> (ladder diagram) explaining how CGN creates an additional round
> trip.
This depends of the deployment scenario.
But it should be clear that in a centralized CGN deployment an additional delay has to be expected. That is at least my interpretation of
draft-ietf-intarea-shared-addressing-issues-05
chapter 7. Geo-location and Geo-proximity
-> "...
   Viewed from the content provider, a
   subscriber behind a CGN geolocates to wherever the prefix of the CGN
   appears to be; very often that will be in a different city than the
   subscriber.
   ..."
Maybe it would be worth to add the mentioning of an additional delay
in the shared-addressing-issues ID.

>
> > > Summary: this seems only useful for 3G/4G, where the host's
> > > IPv4 stack can be changed,
> > Our focus is the fixed network PPP access due BBF TR-178
> respectively
> > WT-242.
> > But you are right for 3G/4G the general mechanism would also be
> > applicable.
> >
> > > and will cause noticeable delays when users
> > > launch applications that need to use IPv4 (delay caused
> by acquiring
> > an address
> > > on demand),
> > We see the delay issue not so critically.
> >
> > > and will be ineffective at its intended goal (avoiding IPv4
> > > address sharing) if "too many" users need IPv4 addresses (e.g., a
> > popular
> > > application is using IPv4 -- Skype, music streaming,
> video streaming,
> > instant
> > > messaging server, imap/pop server, etc.).
> > Of course that can happen, when the application remain on IPv4-only.
> > But here I would expect much more problems when at least
> one NAT444 is
> > in the end-to-end path.
>
> So, after modifying the home gateway to do this, the IPv4 consumption
> will not go down -- each home gateway that has an IPv4 session will
> consume an IPv4 address.
We expect that once IPv6 is introduced, the usage of IPv4 will starting to decrease
Within 1-2 years. So also the IPv4 address consumption should decrease.

>
> What's the likely lifetime of such a solution, considering we have
> already exhausted IPv4 addresses?
We hope to have this implemented before the address exhaustion in Europe occur.
So we see in a saturated market for fixed Internet Access good chances to be successful.


>
> -d
>
>
> >
> >
> > > -d
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: [e-mail]
> > > [mailto:[e-mail]] On
> > > > Behalf Of [e-mail]
> > > > Sent: Tuesday, June 14, 2011 9:46 AM
> > > > To: [e-mail]
> > > > Subject: [Int-area] IETF80 questions regarding "On demand
> > > IPv4 address
> > > > provisioning in Dual-Stack PPP deployment" - Topic for WG?
> > > >
> > > > Hi folks,
> > > >
> > > > right in time before the next IETF in Quebec, we would like
> > > to come up
> > > > again with our Internet Draft
> > > > "On demand IPv4 address provisioning in Dual-Stack PPP
> deployment"
> > > > in order to gather further feedback from the WG.
> > > > During our presentation in Prague I got several remarks and
> > > questions
> > > > and from my understanding there has been some interest in
> > > the approach
> > > > we describe in this I-D.
> > > > Regarding the questions I want to focus on the following
> > > two and will
> > > > try to answer them once more:
> > > >
> > > > - Use case:
> > > > In general we see this mechanism applicable for all
> Dual-Stack PPP
> > > > network scenarios allthrough we focussed our presentation for
> > > > illustrative reasons on routed gateways that may be
> provided by the
> > > > Access Network provider.
> > > > In principle as more IPv4 addresses can be saved, as more
> > > services are
> > > > IPv6 enabled
> > > > (especially those which require always-on connectivity
> (e.g. VoIP,
> > > > mail, update services)) .
> > > > The PPP protocol has not to be changed in order to achieve
> > > the needed
> > > > functionality -
> > > > the described behaviour (of independently releasing and
> > > > refreshing the IPv4 context within a Dual-Stack PPP session)
> > > > is already inherently covered by the existing PPP spec and also
> > > > mentioned as requirements for
> > > > CPEs (see RFC 6204 - WLL-3).
> > > >
> > > > - Efficiency of the mechanism:
> > > > In principle we assume (with ongoing IPv6 deployment) that it is
> > > > possible to save
> > > > after one year of roll-out of the described mechanism about 3%,
> > > > after two years about 8%,
> > > > and after three years up to 13% of the provisioned IPv4
> addresses.
> > > > After 8 years 70% of the IPv4 addresses can be "re-cycled"
> > > according to
> > > > our model calculations.
> > > > (You will find more details here:
> > > > "http://www.ix-
> > > >
> > > konferenz.de/getfoldat.php?vid=1638&t=application/pdf&thema=Ef
> > fizienzab
> > > > schätzung"
> > > > (please copy the whole text between the exclamation marks in the
> > > > address line of you browser).)
> > > >
> > > >
> > > > We plan to come up with a 01 version of the I-D and would that's
> > why
> > > > like to gather more feedback from the WG regarding the possible
> > open
> > > > issues (e.g. what has to be described in more detail,
> ), unanswered
> > > > questions or any other useful hints how to progress with
> > > this work/I-D.
> > > > And of course we are also interested in your opinion if
> this work
> > > > should be done within the Intarea WG or if other WGs
> > > (PPPEXT?) may be
> > > > more appropriate.
> > > >
> > > >
> > > > Thanks and kind regards
> > > >
> > > > KARSTEN Fleischhauer
> > > > _______________________________________________
> > > > Int-area mailing list
> > > > [e-mail]
> > > > https://www.ietf.org/mailman/listinfo/int-area
> > >
> > >
>
>