Re: [shara] [BEHAVE] TR: I-D Action:draft-boucadair-pppext-portrange-option-00.txt

[<[e-mail]>]

Dear Rémi,
 
Thank your for your comments.
 
Please see inline.
 
Cheers
Med

  _____  

De : Rémi Després [mailto:[e-mail]] 
Envoyé : vendredi 6 février 2009 10:40
À : BOUCADAIR Mohamed RD-CORE-CAE
Cc : [e-mail]; [e-mail]
Objet : Re: [BEHAVE] TR: I-D Action:draft-boucadair-pppext-portrange-option-00.txt


Mohamed,

Thanks for this draft.
It does contribute to the promotion of Port-Extended IPv4 addressing, which is the only known way to AVOID, during the IPv4-IPv6 coexistence period, that users MUST depend on CGNs . 

Yet, the mask and value parameters which you propose, to express port ranges, are in my understanding, both too complex and too limited. 
- too complex, because it's hard to imagine a practical use of non contiguous port ranges. (In particular I don't see where to use the chosen example of ports xxx0x1xxxxxxxxxx.) 
[Med] Non contiguous port ranges are only on example. The specification supports both. There is no overhead of the spec which is due to the type of the assigned port ranges 
- too limited, because it cannot express an IPv4-address extension based on dynamic ports, which, as I already discussed in various places, is IMO the most simple choice for a realistic deployment.
[Med] Contiguous port ranges could be used for this purpose.  

For example, no mask and value parameters can express 4-bits address extension based on dynamic ports (i.e. with ports 11EEEExxxxxxxxxx, where Es are the address extension bits). 

If no need is identified for more complex solutions than dynamic-ports only, I then propose to amend the document so that parameters are simplified, e.g. but not necessarily to become:
   Port Prefix Length (6 in the above example).
   Port Prefix Value (11EEEE0000000000 in the above example).
[Med] I need to think about that a little bit more. 

Some other set of parameters could be proposed if  a good reason would be found to also use Well-Known ports and/or Registered ports. (I don't see such a reason, while avoiding interference with firewalls is an important reason  against), 
[Med] I think assigning the overall well known port range to a single user is not **fair**, IMO means to distributed these values should be encouraged. And again, this is naturally supported by our proposal. The values to be carried in an IPCP conf message is out of scope. SP are free to assign the Port Masks they want!

Cheers,

RD