Re: [shara] Updated BOF proposal

Hi,

>I think this is an very important question that needs to be
>figured out about the scope. I think the description needs to
>be clear that it currently proposes an evaluate and pick phase
>on the solution.

I will clarify this to the proposal draft on Monday, with the comments received by that time.

At this point as far as I know the actual proposals are:
1) Transport layer protocol based multiplexing. There will be new draft early next week that combines and evolves draft-boucadair-dhc-port-range and draft-bajko-v6ops-port-restricted-ipaddr-assign, and which proposes using new DHCP options to achieve assignment of port-restricted IPv4 addresses (while of course other address assigning protocols could be extended as well)
2) SAM (draft-despres-sam)
3) IPv4 address + bits from Identification field (no draft)

>I think what technologies that are applicable to this is very
>depending on the problem one tries to solve. One of the big
>questions I have on the problem statement is what classes of
>legacy application you intended to support.
>
>Legacy client to sever application where the client towards
>the external uses an fractional address and which doesn't
>matter. Works fine with any allocation of address.

For this class of applications the benefits would be distribution of NAT to/toward edges instead of core. This is one of big benefits, I believe.

>Legacy application that have some IPv4 NAT traversal
>capabilities but still some specific requirements like
>particular port ranges or adjacent ports. Can they still work
>under a limited port range? Or do you need to capability to
>request and assign specific ports?

Generally these proposals would not provide all the benefits of IPv4, thus we recommend moving to IPv6 as fast as possible.

In worst case the legacy application would face the same environment as with any NATed access, as the port restricted IPv4 address can be hidden from these applications by host-internal NAT. Thus applications trying to utilize specific ports (like IANA assigned) or port ranges would face similar trouble as when trying to work with privacy addresses. Thus the proposals shuld not be making life more difficult for unmodified apps.

However, a modified application could gain at least following benefits over NATed address (on the drafts listed as reading there are probably more that I immediately recall):
- host a server in one of the allocated public ports (provided rendezvous protocols allow communication of port as well)
        -> similar functionality is possible with UPnP/NAT-PMP, provided NAT allows control - which it always does not
- avoid use of STUN, as the public address would be known already
- perhaps fasten ICE procedures, if address candidate set would be smaller
- avoid sending of NAT-keepalives (may still need firewall keepalives..)

Now depending on proposal there is or is not possibility to get adjacent ports. I had forgotten that requirement of some real-time (right?) apps. I have never really understood why the adjacent port design was made - it makes implementations more complex. Is it to simplify creation of ALGs/firewall rules? That could be a problem to be sorted out.

Best regards,

        Teemu
_______________________________________________
shara mailing list
shara@ietf.org
https://www.ietf.org/mailman/listinfo/shara