Re: [Pppext] new PPP-related individual submission

[James Carlson <[e-mail]>]

On 09/13/10 09:41, [e-mail] wrote:
> 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.
> 
> 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/.

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.

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

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

> I don't understand that answer.  PPP and DHCP are in no way mutually
> exclusive protocols.
> 
> 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.

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

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