Re: [Pppext] new PPP-related individual submission

[<[e-mail]>]

Dear James; 

Please see inline.

Cheers,
Med 

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

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.

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)

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.

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

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.

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.

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

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

> 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]>

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