Subject: [Pppext] new PPP-related individual submission

From: James Carlson <[email-masked]>
Date: Wed, 08 Sep 2010 10:58:52 -0400

Forwarded from I-D Announce:

Subject: I-D Action:draft-boucadair-pppext-portrange-option-02.txt
Date: Tue,  7 Sep 2010 22:30:02 -0700 (PDT)
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

    Title           : Port Range Configuration Options for PPP IPCP
    Author(s)       : M. Boucadair, et al.
    Filename        : draft-boucadair-pppext-portrange-option-02.txt
    Pages           : 13
    Date            : 2010-09-07

This memo defines two IPCP (IP Configuration Protocol, [RFC1332])
Options to be used in the context of Port Range solutions.  IPCP is
the configuration protocol used when PPP (Point-to-Point Protocol,
[RFC1661]) is deployed.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-boucadair-pppext-portrange-option-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

-- 
James Carlson         42.703N 71.076W         <[email-masked]>

---

From: James Carlson <[email-masked]>
Date: Wed, 08 Sep 2010 14:37:10 -0400

>     Filename        : draft-boucadair-pppext-portrange-option-02.txt

I've read through this draft, and I have a number of questions; some
broadly architectural and some in the details of this draft.

As an architectural issue, I don't quite see how this will work for the
majority of IPv6 tunneled links in use today.  For example, I'm
connected to the IPv6 backbone via Hurricane Electric, which uses a
simple IP-IP tunnel.  My IPv4 provider (Comcast) is not and need not be
aware of this tunnel in order for it to work.  There are no port numbers
or "SLA ID" numbers that could be used for the v4 provider to demux links.

So, in reference to IPv6 tunnel deployment, is it true that only 6to4
addresses can be supported by this mechanism?  Are there any IPv6
providers doing that?

As a second architectural issue, I don't quite understand how IPSec will
work.  As I understand it, the NAT traversal mechanism assumes that
addresses/ports change when going across a NAT, so the peers "know" that
something special is going on and they need to adjust.  But how do two
IPSec speakers know that one or the other (or possibly both) peers
merely have port range and usage restrictions?  Is it required that when
port-range restriction is in place, the customer must always use NAT as
well and make sure any IPSec traffic goes through the NAT?

As a third architectural issue, what happens when two distinct end
systems sharing a single IP address but with distinct port ranges
attempt to talk to each other?  How does one of these devices know that
the IP packet being sent isn't destined locally for an unavailable port?
 What changes are necessary to RFC 791 itself to make external
transmission of for-self packets possible?

(For what it's worth, I think that if the draft were disconnected from
the address assignment mechanism, it would be better for all involved.
What I think this system really represents is a way to configure remote
NAT systems at the customer site(s) with non-overlapping port ranges on
shared IP addresses.  That should be a helpful feature regardless of how
addresses are assigned or what datalink layer protocol is in use.  There
should be a "discover NAT configuration" protocol; perhaps implemented
using DHCP INFORM or similar protocol.)

Getting closer to the draft details, it seems that you've got DHCP hooks
for this feature.  That's good.  But why can't those same hooks be used
over PPP?  Either negotiate private addresses or no addresses at all (if
you wish) and then just do the same port-range allocation you'd do via
DHCP.  Why modify both DHCP and PPP?

I don't understand how this option can be considered "MANDATORY," as
there are many PPP implementations out in the field, and we (the IETF)
have no power to force any of them to change.  Some commentary on this
might be needed.  (Perhaps what the draft means here is that if the BRAS
device's policy insists on port ranges, and the peer doesn't agree, then
the link should fail.  In that case, I don't think sending back an IPCP
Configure-Ack for 0.0.0.0 is wise.  It'd be much better to do an
unsolicited IPCP Configure-Nak, or an LCP Protocol-Reject for IPCP, or
even LCP Terminate-Request instead.  Agreeing to 0.0.0.0 is quite
misleading.)

I think the text would be much clearer if the use of the option in
Configure-Request and Configure-Nak were specified separately.  For
instance, can a user request a particular size of range by hinting with
mask set non-zero in an initial Configure-Request?

The draft does not say what to do with error cases (e.g., a bit set to 1
in the value where the same bit position has a 0 in the mask).  It
should be better specified what each peer ought to do when faced with
unexpected data.

I don't think it makes sense to have two separate options for this
feature.  A single option containing both value and mask would make more
sense to me, because the options can't be used independently and the
option number space isn't limitless.

Perhaps just a nit, but I don't think it's really necessary to limit
either side to just port-range option.  PPP already has pretty
well-defined ways for handing multiple options (either take-all or
take-first), so outlawing multiple might not be necessary.

Finally, I don't think this works as an individual submission.
Allocating IPCP code points requires IETF Consensus, which typically
means working within the PPPEXT working group; see RFC 3818.  If you
want to go ahead without working group review, I suggest looking into
the Vendor-Specific Option -- see RFC 2153.

---

From: <[email-masked]>
Date: Mon, 13 Sep 2010 09:09:00 +0200

Dear James,

Thank you for your comments.

My answers inline.

FYI, a new updated version is available at:  http://www.ietf.org/id/draft-boucadair-pppext-portrange-option-03.txt

Cheers,
Med

-----Message d'origine-----
De : James Carlson [mailto:[email-masked]] 
Envoyé : mercredi 8 septembre 2010 20:37
À : BOUCADAIR Mohamed NCPI/NAD/TIP; LEVIS Pierre RD-BIZZ; GRIMAULT Jean-Luc RD-MAPS; VILLEFRANQUE Alain RD-BIZZ
Cc : [email-masked]
Objet : Re: [Pppext] new PPP-related individual submission

Med: Architectural issues are out of scope of this document. Please refer to http://tools.ietf.org/html/draft-boucadair-port-range-02 or http://tools.ietf.org/html/draft-ymbk-aplusp-05 for more architectural discussion. BTW, an IPv6-centric solution is defined in http://tools.ietf.org/html/draft-boucadair-behave-ipv6-portrange-04.

Med: This is not an issue. Please refer to tests that we have undertaken to assess this behaviour http://tools.ietf.org/html/draft-boucadair-behave-bittorrent-portrange-02#section-4.3 and the results are listed in http://tools.ietf.org/html/draft-boucadair-behave-bittorrent-portrange-02#section-5. These tests demonstrated that no issue has been encountered when two machines having the same IP address communicate together.

Med: I added this note to the introduction: "IPv4 address exhaustion is only provided as an example of the usage of the PPP IPCP Options defined in this document. In particular, Port Range Options may be used independently of the presence of IP-Address IPCP Option."

Med: Because some operators have PPP in their networks and not DHCP. 

Med: The options are not mandatory. The text you are referring to was about an example where the server can only assign shared IP addresses; otherwise 0.0.0.0 is returned.  

Med: We will consider enhancing the text.

Med: The two options are now merged.

Med: Our plan was to submit this document as individual submission, but if there is an interest of pppext to work on this feature, we can re-consider our plans. Please advise.
*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************

---

From: James Carlson <[email-masked]>
Date: Mon, 13 Sep 2010 09:19:03 -0400

> FYI, a new updated version is available at:  http://www.ietf.org/id/draft-boucadair-pppext-portrange-option-03.txt

Thanks for the update.

If possible, standard quoting would be appreciated.  Otherwise, it'll
become hard to attribute text to authors in the thread.

> Med: Architectural issues are out of scope of this document. Please refer to http://tools.ietf.org/html/draft-boucadair-port-range-02 or http://tools.ietf.org/html/draft-ymbk-aplusp-05 for more arc…

Those references seem to indicate that only certain "structured" IPv6
addresses will work with this scheme, which I think answers my question.

I understand that it's out of scope for this particular draft.  The
reason I asked was to be sure I understood the material.

> Med: This is not an issue. Please refer to tests that we have undertaken to assess this behaviour http://tools.ietf.org/html/draft-boucadair-behave-bittorrent-portrange-02#section-4.3 and the resul…

I don't believe those reference materials answer my question, because
the modifications on CPE-1 and CPE-2 that must have been necessary seem
not to be described.

To make the question more detailed in the context of this draft: I do
not understand how the IP stack in CPE-1 could have a packet with
destination address 193.51.145.206 and then decide that this packet
belongs to CPE-2 (and thus needs to be forwarded to PRR) without
modifications to the IP stack that cause inspection of the transport
layer headers.

I suspect that one of the underlying assumptions here is that
peer-to-peer communication is not necessarily possible.  T1 cannot send
packets that go straight to T2.

> Med: I added this note to the introduction: "IPv4 address exhaustion is only provided as an example of the usage of the PPP IPCP Options defined in this document. In particular, Port Range Options…

That's an improvement, but not what I was suggesting.  To make it more
direct: I am unconvinced that transport-layer port range restrictions
are really the sort of issue that should be negotiated down at the
datalink (PPP) layer.  There ought to be a more common way to do this.

> Med: Because some operators have PPP in their networks and not DHCP. 

I don't understand that answer.  PPP and DHCP are in no way mutually
exclusive protocols.

Should we eventually add all DHCP options into PPP?  Why?  How hard is
it to send a single UDP packet and get one in reply for DHCP INFORM?
How hard is it compared to modifying many different PPP implementations
around the world?

If we could get away with adding an option to just one more general
protocol rather than two separate protocols, wouldn't that be a simpler
result?

> Med: The options are not mandatory. The text you are referring to was about an example where the server can only assign shared IP addresses; otherwise 0.0.0.0 is returned.  

I suggest a rewording to avoid "mandatory."  Perhaps "required by the
BRAS policy configuration" would be more accurate.

In any event, I do not think it's wise to send IPCP Configure-Ack for
address 0.0.0.0.  If the lack of this option means that the Host system
will be unable to use IP with the BRAS, then the behavior should be
either shutting down IPCP (using Protocol-Reject or by just giving
Configure-Nak until the link times out) or shutting down the entire link
with LCP Terminate-Request.

Allowing IPCP to go to Opened state with negotiated parameters that are
known to be unusable is very much against the intent of PPP negotiation.
 I don't agree that this is a good solution to the problem.

> Med: Our plan was to submit this document as individual submission, but if there is an interest of pppext to work on this feature, we can re-consider our plans. Please advise.

I don't believe that this work (as it is presently drafted) can or
should go forward without approval of the PPPEXT working group due to
the requirements of RFC 3818.  That document requires consensus to add
new options.

> This message and any attachments (the "message") are confidential and intended solely for the addressees. 

Please remove or disclaim this text in any future transmission on this
list.  It's not appropriate for IETF communications, because these
messages are not being kept confidential.

---

From: <[email-masked]>
Date: Mon, 13 Sep 2010 15:41:59 +0200

Dear James, 

Please see inline.

Cheers,
Med 

-----Message d'origine-----
De : James Carlson [mailto:[email-masked]] 
Envoyé : lundi 13 septembre 2010 15:19
À : BOUCADAIR Mohamed NCPI/NAD/TIP
Cc : [email-masked]; [email-masked]; [email-masked]; LEVIS Pierre RD-BIZZ; GRIMAULT Jean-Luc RD-MAPS; VILLEFRANQUE Alain RD-BIZZ
Objet : Re: [Pppext] new PPP-related individual submission

Thanks for the update.

Med: What about the configuration details provided in: http://tools.ietf.org/html/draft-boucadair-port-range-01#appendix-B, especially http://tools.ietf.org/html/draft-boucadair-port-range-01#appendix-B.2? Does this answer your concern? FWIW, another implementation candidate can be found here: http://software.merit.edu/pe-arp/.

Med: P2P communications are possible but need to cross the port range router. Please refer to the text report I mentioned in my earlier message.

Med: Do you have any solution candidate in mind?

Med: What I meant is: what SPs which do not have DHCP in their networks have to do in order to support port-range solution?

Med: The text proposal is OK with me.

Med: I personally don't have any preference among all these options including the one we described in the draft. I will add a note to the draft to list the options.

Med: Sorry, I cannot control this. This is added automatically.

---

From: James Carlson <[email-masked]>
Date: Mon, 13 Sep 2010 21:02:17 -0400

> Med: What about the configuration details provided in: http://tools.ietf.org/html/draft-boucadair-port-range-01#appendix-B, especially http://tools.ietf.org/html/draft-boucadair-port-range-01#appen…

Yes, I saw that.  I don't see how this accomplishes what's needed or
addresses the question I had.

Since it seems we're not getting anywhere on this, and it's not directly
related to the draft (just whether this can be deployed ... hopefully
somewhere far from me), I guess I'll give up now.

> Med: P2P communications are possible but need to cross the port range router. Please refer to the text report I mentioned in my earlier message.

That's exactly the question -- how they're forced to cross the "PRR" for
all traffic with just a postroute hook.  I was sort of hoping for an
architectural description of the solution rather than a list of products
used.

As I said above, I'll just stipulate that some system could be hacked up
to do this.

> Med: Do you have any solution candidate in mind?

Yes.  Define a DHCP option (as you've already done) that defines port
ranges for NATs to use.  Then use that.

> Med: What I meant is: what SPs which do not have DHCP in their networks have to do in order to support port-range solution?

If they really have no DHCP at all, then they have a burden of writing a
200 line UDP application that reads DHCP INFORM messages and sends out
replies.

In fact, that tiny application is no more complex than the proposed
changes to PPP.  It's exactly the same information -- i.e., given a
particular link to a remote site, which ports should it use? -- and it
does the same work.

If they do have DHCP already, then they should not need to do anything
more than upgrading the configuration to include this new option.  At
most, they might need a DHCP relay in the PPP server.  This buys them
the new "port range feature" along with all the rest of the very useful
options (such as DNS server addresses, time servers, and the like) that
DHCP already offers.

And it's still stateless.  DHCP INFORM requires no per-peer state.

(A much better idea still, I believe, would be to go through the normal
process of creating a new IETF working group to work out the right
architecture for a feature like "port range restriction" and have that
group work out the details in collaboration with the existing groups.
Unless I'm missing something important here, it looks like this is being
done as a flurry of individual submissions.  That's sometimes ok for
minor experiments and self-contained extensions, but for fundamental
architectural issues that cross dozens of different protocols, I'm not
sure I agree that it's the most effective approach.)

I'm not seeing a good rationale for modifying PPP.

> Med: I personally don't have any preference among all these options including the one we described in the draft. I will add a note to the draft to list the options.

If there are others on the list with opinions, I'd like to hear from them.

But I don't think it's wise to include Configure-Ack 0.0.0.0 as one of
the possible solutions to this problem.  It's misleading at best, and
very likely to cause interoperability problems and very strange failure
modes.

Configure-Ack means "I agree to your proposal."  It doesn't ever mean "I
no longer care what you think and I'm going to start ignoring your packets."

I can't see a good excuse for it.

> Med: Sorry, I cannot control this. This is added automatically.

Might I suggest a gmail or other free account?

It really does come down to an issue of legal liability.  Including that
note on your messages virtually guarantees that some folks will refuse
to engage in any constructive discussion on this thread -- even if they
agree with you and wish to support the proposal -- and greatly muddies
the waters if Nokia ever does decide to pursue IPR.

---

From: Vernon Schryver <[email-masked]>
Date: Tue, 14 Sep 2010 02:46:52 GMT

> From: James Carlson <[email-masked]>
> To: [email-masked]
> Cc: "[email-masked]" <[email-masked]>,
>         "[email-masked]" <[email-masked]>,
>         VILLEFRANQUE Alain RD-BIZZ <[email-masked]>,
>         GRIMAULT Jean-Luc RD-MAPS <[email-masked]>,
>         LEVIS Pierre RD-BIZZ <[email-masked]>,
>         "[email-masked]" <[email-masked]>

> If there are others on the list with opinions, I'd like to hear from them.

I've not seen a cogent response to the J.Carlson's point that instead
of PPP, DHCP is a far better place to solve the problem for theoretical
architectural or layering reasons as well as practical implementation
reasons.

> very likely to cause interoperability problems and very strange failure

That description Configure-Ack 0.0.0.0 is extremely polite and gentle.
With permission and a promise of amnesty for being other than polite,
I would say a little what I think of any proposal that includes
Configure-Ack 0.0.0.0 even just as an alternative.

>From context, "this" appears to refer to the following notice on
M.Boucadair's email about his proposal:

] This message and any attachments (the "message") are confidential and intended solely for the addressees. 
] Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
] France Telecom Group shall not be liable for the message if altered, changed or falsified.
] If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
] 

> the waters if Nokia ever does decide to pursue IPR.

That's a good point, but isn't it too late to switch to gmail?
Since he has evidently been willingly and knowingly including those
notices on his comments, isn't the entire IETF including the PPP and
DHCP WGs prohibited from considering them?  Doesn't M.Boucadair's
statement about those notices require that we take cognisance of the
notices and treat everything he has said and might later say from any
account about his proposal as contrary to the IETF "Note Well"?  See
http://www.ietf.org/about/note-well.html
No reasonable and prudent person ignores assertions of confidentiality
of technical discussions.

Vernon Schryver    [email-masked]

---

From: <[email-masked]>
Date: Tue, 14 Sep 2010 07:25:48 +0200

Dear James; 

Please see inline.

Cheers,
Med 

-----Message d'origine-----
De : James Carlson [mailto:[email-masked]] 
Envoyé : mardi 14 septembre 2010 03:02
À : BOUCADAIR Mohamed NCPI/NAD/TIP
Cc : [email-masked]; [email-masked]; [email-masked]; LEVIS Pierre RD-BIZZ; GRIMAULT Jean-Luc RD-MAPS; VILLEFRANQUE Alain RD-BIZZ
Objet : Re: [Pppext] new PPP-related individual submission

Med: The configuration provided in the document is only an example of how the system can be implemented using private IP addresses as a routing identifier (see the architecture draft for more details about this point). Indeed, this routing identifier is required for the delivery of incoming packets destined to a shared IP address. The port range router is responsible for this task. All incoming traffic destined to a given shared address will be received by a PRR (because a route has been announced). The IPCP options draft does not go into these details because it is out of its scope. Architectural considerations are covered in other documents. Furthermore, we have tested which assess the validity of the concept. These tested are both IPv4 Port range and IPv6-based port range (i.e., IPv6 is used to encapsulate IPv4 traffic)

Med: The traffic will be forced to cross a PRR because of routing configuration. This is documented in the architecture documents.

Med: But, we don't have NAT in the port range solution! The basic idea of what we are doing is to avoid introducing a level of NAT in the server provider domain.

Med: We are not modifying PPP; We are just defining new options to convey an information required for the provisioning of the IP connectivity when IPv4 addresses are rare resources (now).

---

From: James Carlson <[email-masked]>
Date: Tue, 14 Sep 2010 07:17:02 -0400

> Med: But, we don't have NAT in the port range solution! The basic idea of what we are doing is to avoid introducing a level of NAT in the server provider domain.

The solution you've described does seem to assume a NAT at the CPE side.
 Without one, some basic IP functionality just won't work.

That's the NAT that's being configured by the range specified.  I agree
that you've got a possibility to have a few static ports (within the
constrained range) that the CPE device uses for non-NAT purposes, but I
don't agree that the possible use of these changes the basic structure
of the scheme.

> Med: We are not modifying PPP; We are just defining new options to convey an information required for the provisioning of the IP connectivity when IPv4 addresses are rare resources (now). 

New options are a modification.  It's hard to see how these options
could possibly work without having modified PPP (specifically IPCP) code
in cooperating devices.

After considering this discussion, I'm not inclined to endorse this
draft at this time.

The underlying idea is interesting to me, though I do think that
providing incentives for better v6 connectivity and having carrier-based
NAT for certain networks are both more conventional and more easily
deployed solutions, but I do not agree that putting the options into
IPCP is the right way to go about implementing it.  If this solution can
be deployed, the same issues will need to be addressed on datalinks
other than PPP, and it's unclear to me how, why, or if those parts of
the solution would be based on equivalent datalink modifications.