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

["Dan Wing" <[e-mail]>]

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Thursday, June 23, 2011 2:53 PM
> 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?
> 
> > -----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.

I am not aware of any sort of NAT deployment that adds a round
trip to the CGN.

> 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.

It is true that deploying a CGN in a far-away place adds propagation 
delay.  But propagation delay is also added by forcing routing to a
far-away location with route preferences or tunnels.  Propagation delay
is propagation delay, and to avoid it requires distributing (rather
than centralizing) routers, CGNs, and tunnel termination devices.  
Most vendors have tiny delays for the NAT processing itself 
(microseconds).

However, the geolocation problem you quoted above also exists with 
the mechanism scheme you are proposing.  For example, a certain IP
address, e.g., 161.44.1.1, would be "loaned" to someone in Berlin
on Monday morning, and then "loaned" to someone else in Frankfurt 
on Monday afternoon.

To prevent the geolocation problem, only certain subnets would
be loaned in each city (e.g., 161.44.1.0/24 is Frankfurt, 161.44.2.0/24
is Berlin, etc.).  The same exact thing can be done with a *single* CGN
located in one city -- the CGN can assign 161.44.1.0/24 to users
from Frankfurt, 161.44.2.0/24 to users from Berlin, etc.  Which is
how location is handled today, anyway, in the absence of CGN and
the absence of address borrowing.


> 
> >
> > > > 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.

Yes, I believe we all expect it to decrease.

But if it doesn't, where does this leave the engineering IETF would have
expended on this additional transition technology.  For example, what if 
Skype continues to grow but still requires an IPv4 connection.  What if
Yahoo
IM, AOL IM, Microsoft IM, or other popular services with long-lived 
connections (IM) or frequent connections (IMAP, DNS) don't have clients 
and servers that support IPv6.

My point is that loaning an IPv4 address is only suitable if the demand
long-lived and frequent IPv4 connections really _does_ diminish for that
specific community of users.  If it does not diminish for that specific
community of users, the effort is for naught.

> > 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
> >
> >
> > >
> > >
> > > > -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
> > > >
> > > >
> >
> >