Subject: [BEHAVE] Comments on draft-boucadair-dhc-port-range-01.txt

From: Dave Thaler <[email-masked]>
Date: Thu, 6 Nov 2008 10:06:23 -0800

In addition to the comments I sent on draft-boucadair-port-range-00.txt, here's some that apply specifically to this draft.

1)      The concept of asking for one or more ports to be allocated seems to overlap to a large extent with NAT-PMP in draft-cheshire-nat-pmp-03 (and work on UnP IGD v2 for that matter).  The main difference seems to be that this draft asks for a block, whereas NAT-PNP asks for one.

2)      The use of non-contiguous masks rather than a set of ranges seems cumbersome.  Non-contiguous subnet masks were originally possible but then abandoned because no one could really understand them.  This seems to repeat that same problem.  In addition, I'll point out that masks constrain you to a power-of-two, whereas ranges allow arbitrary sizes.

3)      Sections 3.1 and 3.2 imply that the DHCP client device (CPE) is responsible for informing the service provider's router what port range the service provider's DHCP server allocated.  There's a trust problem there... why would a router trust a customer to provide it what amounts to routing information?  This isn't what people do today.  Instead the DHCP server/relay can talk to the router as needed, since they're all under the control of the same provider.  This is generally how prefix delegation works.  It's also consistent with the model where the DHCP server updates a DNS server (rather than allowing clients to use dynamic update).

-Dave Thaler
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: <[email-masked]>
Date: Mon, 10 Nov 2008 10:19:04 +0100

Dear Dave, all,
 
Please see inline my answers.

In addition to the comments I sent on draft-boucadair-port-range-00.txt,
here's some that apply specifically to this draft.
[Med] We are currently preparing our answers to your comments on
draft-boucadair-port-range-00. We will send them soon. 

1)      The concept of asking for one or more ports to be allocated
seems to overlap to a large extent with NAT-PMP in
draft-cheshire-nat-pmp-03 (and work on UnP IGD v2 for that matter).  The
main difference seems to be that this draft asks for a block, whereas
NAT-PNP asks for one.

[Med] In our proposed solution, we don't ask for a port number or a set
of numbers. The information related to allowed port numbers, to be used,
are part of the IP connectivity configuration which is conveyed by the
Service Provider to its customers (connected device). By the way, I will
read the draft-cheshire-nat-pmp-03 in depth. 

2)      The use of non-contiguous masks rather than a set of ranges
seems cumbersome.  Non-contiguous subnet masks were originally possible
but then abandoned because no one could really understand them.  This
seems to repeat that same problem.  In addition, I'll point out that
masks constrain you to a power-of-two, whereas ranges allow arbitrary
sizes.

[Med] The concept we are proposing is not to be confused with a SUBNET
MASK. In this draft, we are dealing with Port Masks. The kind of
information carried in a port is hardly comparable with the kind of
information carried in a subnet. Subnets are by essence hierarchical,
which has no real meaning for ports. As shown in
draft-boucadair-dhc-port-range-01 complicated scenarios (e.g. 128 port
ranges, balanced distribution of well-known port values among several
customers, etc.) are doable easily with a single mask. 

As for your second comment, subnet masks restrict as well the range of
addresses to a power of two! We think masks are easier to handle by
software. Therefore despite this limitation we think it is interesting
to consider port masks.   

3)      Sections 3.1 and 3.2 imply that the DHCP client device (CPE) is
responsible for informing the service provider's router what port range
the service provider's DHCP server allocated.  There's a trust problem
there... why would a router trust a customer to provide it what amounts
to routing information?  This isn't what people do today.  Instead the
DHCP server/relay can talk to the router as needed, since they're all
under the control of the same provider.  This is generally how prefix
delegation works.  It's also consistent with the model where the DHCP
server updates a DNS server (rather than allowing clients to use dynamic
update).

[Med] Agreed. As mentioned in draft-boucadair-port-range-00, two
alternatives (CPE-Provisioned PRR and Provider-Provisioned PRR) may be
considered to build the binding table (maintained by the PRR). Service
Providers should make their engineering choices according to their
design and architecture policies. We only provide to them a toolkit.
Service Providers are free to implement the option which meets its
internal engineering policies.

-Dave Thaler

Cheers

Med