Re: [Pppext] new PPP-related individual submission

[James Carlson <[e-mail]>]

On 09/14/10 01:25, [e-mail] wrote:
> Yes.  Define a DHCP option (as you've already done) that defines port
> ranges for NATs to use.  Then use that.
> 
> 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.

> I'm not seeing a good rationale for modifying PPP.
> 
> 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.

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