Subject: [Int-area] FW: questions about draft-fleischhauer-ipv4-addr-saving

From: "George, Wes" <[email-masked]>
Date: Wed, 16 Nov 2011 00:15:04 -0500

As requested, here are the comments I made directly to the authors regarding the -01 revision, and authors' answers.

Thanks,

Wes
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, September 16, 2011 8:54 AM
To: George, Wesley
Cc: [email-masked]; [email-masked]
Subject: AW: questions about draft-fleischhauer-ipv4-addr-saving

Dear George,

Please find my comments inline.

Best

KARSTEN

> -----Ursprüngliche Nachricht-----
> Von: George, Wesley [mailto:[email-masked]]
> Gesendet: Freitag, 9. September 2011 15:23
> An: [email-masked]
> Betreff: questions about draft-fleischhauer-ipv4-addr-saving
>
> Hello -
>
>
>
> I find this draft interesting and I think that it has the potential to
> be very helpful. This is certainly a gap in current dual-stack
> implementations. I might note that there is similar work that needs to
> be undertaken within the DOCSIS spec and probably 3GPP. You may wish
> to mention this as follow-on work in the intro for your draft.
KF: Yes we will do this.
AFAIK 3GPP is rather tending to use just Dual-Stack or NAT/DNS64 approaches.
Since DT Germany has no DOCSIS network we can not drive the activities here.
>
> Also, I have a few questions/comments about the draft -
>
>
>
> First, I cannot find any reference within the draft to the timescale
> upon which this on-demand IPv4 provisioning must happen. Since this
> assumes that private hosts would issue a DHCP request to the local CPE
> to get a private IPv4 address as they do today, the individual hosts
> would have no way of knowing that the upstream connection does not
> actually have
> IPv4 connectivity, and would assume that it works. I would expect that
> unless the CPE is operating such that it is actually proxying the
> initial connection request from the local private hosts to make it
> seem like the connection was successful (eg responding locally to TCP
> syn messages, etc), it would have to complete the setup very rapidly
> (a few hundreds of ms) in order to not have the connection attempt
> time out or fail. Your draft should discuss the feasibility of this
> rapid provisioning window within today's PPP environment. It may be
> appropriate to look at things like the throughput accelerators that
> are often used on IPoverSatellite and other high-latency connections
> which do some tricks to make TCP think that the RTT is much lower than
> it is in order to improve throughput. Some sort of similar mechanism
> may be appropriate here to locally proxy during the gap and prevent
> request timeouts while the IPv4 address on the WAN interface is being
> requested.
KF: That is an valid point, that we will analyse within the lab.
In theory we expect here a similar behaviour as it is today when PPP is used on demand.
Instead setting up the whole PPP session we have just setup IPCP.
We are thinking that this should take not so much time.

>
>
>
> Second, I recommend adding a use case (and a definition in
> 3.1) where the CPE is separated into two devices, one that carries the
> PPP session (eg a standalone DSL modem) and the other that is
> operating simply as a local router. In this case, the NAT44 function
> and any IPV6 PD/ND + DHCP for both stacks lives on the router, but the
> PPP session lives on the other device. I think that this is a very
> common case, and would dramatically improve the applicability of this
> idea.
KF: Good idea. We could try at least to divide the CPE into 4 parts.
Application (e.g. VoIP SIP UA), router and layer 1/2 modem.
We want to introduce this also for FTTx, so we are careful in defining layer1/2 usecases.
ASFAIK IETF drafts provide 72 symbols per line.
The creation of the current figure leads to some pain ;(.
But I hope we will find a solution here.

>
> In this case, ideally you would want the implementation of this spec
> to happen on the device that holds the PPP session, in such a way that
> it is transparent to the downstream device. This gives the consumer
> the ability to choose an appropriate GW device without consideration
> for whether it supports this functionality or not. This transparency
> is difficult and indeed may be impossible since standard behavior for
> CPE routers is that they immediately make a request for an outside
> IPv4 address on startup, and do not have a concept of requesting it on
> demand. It may therefore make sense to recommend a solution for
> standalone devices like this, perhaps a DHCP option code that says
> "send a new request when you actually have IPv4 traffic, and I'll give
> you an address" so that the device knows that the DHCP server has
> responded, but does not require a constant IPv4 address.
KF: We are thinking that the address saving feature is only useful in a Dual-Stack PPP connection. Our prefered second NCP would be IPv6.
Also in the case of a pure Dual-Stack service offering we have to consider IPv4-only Or maybe later IPv6-only CPE.
For an IPv4-only CPE I would see no reason to establish LCP without an immediate demand of IPv4 communication.
So we would expect here an IPCP request from the CPE.
When the CPE does not send an IPCP or IPv6CP request to the NAS And therefore no NCP is active we would terminate the PPP session.

>
>
>
> Lastly, I think that there is some opportunity to note some methods to
> improve the likelihood that devices in this configuration can actually
> spend a significant amount of their time operating in IPv6-only mode -
> for example - ensure that the device is configured with IPv6 DNS
> server addresses so that an IPv4 address is not required for DNS. It
> would be useful to note that Windows XP, for example does not have the
> ability to use IPv6 for DNS requests, and would require a local proxy
> to be implemented that would listen for IPv4 DNS requests locally but
> would make the actual lookup via IPv6.
> This does not mean that the device must do DNS64, only that it must be
> capable of listening for DNS requests via IPv4
> *transport* but make the upstream request to its configured DNS server
> via IPv6 *transport*.
KF: Goof idea. We will add a section which describes this.
AFAIK at least the BBF IPv6 CPE document mentioned this already.
We will describe this and refer to those documents.

> Thanks,
> Wes George

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: <[email-masked]>
Date: Tue, 22 Nov 2011 18:10:50 +0100

Dear Wes,

unfortunately we didn't achieve to publish a version 02 of the draft.
That will happen until IETF83.
In this version we will consider your comments.

Best

KARSTEN

> Von: [email-masked]
> [mailto:[email-masked]] Im Auftrag von George, Wes
> Gesendet: Mittwoch, 16. November 2011 06:15
> An: [email-masked]
> Betreff: [Int-area] FW: questions about
> draft-fleischhauer-ipv4-addr-saving
>
> As requested, here are the comments I made directly to the
> authors regarding the -01 revision, and authors' answers.
>
> Thanks,
>
> Wes
> Cc: [email-masked];
> [email-masked]
> KF: We are thinking that the address saving feature is only
> useful in a Dual-Stack PPP connection. Our prefered second
> NCP would be IPv6.
> Also in the case of a pure Dual-Stack service offering we
> have to consider IPv4-only Or maybe later IPv6-only CPE.
> For an IPv4-only CPE I would see no reason to establish LCP
> without an immediate demand of IPv4 communication.
> When the CPE does not send an IPCP or IPv6CP request to the
> NAS And therefore no NCP is active we would terminate the PPP session.
>
> >
> >
> >
> This E-mail and any of its attachments may contain Time
> Warner Cable proprietary information, which is privileged,
> confidential, or subject to copyright belonging to Time
> Warner Cable. This E-mail is intended solely for the use of
> the individual or entity to which it is addressed. If you are
> not the intended recipient of this E-mail, you are hereby
> notified that any dissemination, distribution, copying, or
> action taken in relation to the contents of and attachments
> to this E-mail is strictly prohibited and may be unlawful. If
> you have received this E-mail in error, please notify the
> sender immediately and permanently delete the original and
> any copy of this E-mail and any printout.
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area
>