Re: [Pppext] new PPP-related individual submission

[James Carlson <[e-mail]>]

>     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

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.

-- 
James Carlson         42.703N 71.076W         <[e-mail]>