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é : lundi 13 septembre 2010 15:19
À : 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

[e-mail] wrote:
> 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.

> De : James Carlson [mailto:[e-mail]] 
> Envoyé : mercredi 8 septembre 2010 20:37
> > 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?
> 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.

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.

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

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.

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

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.

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

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?

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

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?

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?

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

Med: The text proposal is OK with me.

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

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

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

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