Subject: Re: [shara] Updated BOF proposal

From: <[email-masked]>
Date: Fri, 30 Jan 2009 09:26:49 +0100

Hi,

IMHO there's third: we look at solution proposals currently not worked on elsewhere and during WG work pick the one that fulfills the agreed requirements best (including requirements of timing and complementing of existing solutions).

That is why this is currently openly scoped.

Personally, I can agree on focusing this BOF to just "port ranges" and then discuss on details of how that is accomplished (e.g. With DHCP). But I prefer having rough consensus on the scope instead of just pushing for what I myself prefer.

I'd love to see opinions from still more people reading this list.

Best regards,

Teemu

--- original message ---
From: "ext [email-masked]" <[email-masked]>
Subject: RE: [shara] Updated BOF proposal
Date: 30th January 2009
Time: 8:23:17 am

Thank you Teemu for this update,

I guess we still need to precise a bit more the scope of shara.
"Sharing of an IPv4 Address" is the very generic target for all solutions that deal with IPv4 access, using IPv4, in the context of IPv4 public address exhaustion.
So, it encompasses both CGN solutions (including: DS-lite, Double NAT, and other flavors that I guess are around and soon to be released -I'm not involved in them!-, ...) and "port range" solutions (the reading list you mention), as well as some more exotic approach as the ident bits use, pointed out by Randy.

So, there are two extreme possible positions:

1) We only deal with "port range" solutions
2) We deal with all solutions but DS-lite (which is for softwire)

I think we must but very clear and explicit on this matter.

Regards

Pierre

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]]
> De la part de [email-masked]
> Envoyé : jeudi 29 janvier 2009 16:27
> À : [email-masked]
> Objet : [shara] Updated BOF proposal
>
> Hi,
>
> I updated the BOF proposal
> (http://trac.tools.ietf.org/bof/trac/wiki/SHARABOF). All
> comments, including text suggestions, are welcome:
> --
> Sharing of an IPv4 Address (shara) BOF
> --------------------------------------
>
> Agenda draft:
> -------------
>
> 1. Introduction, Agenda, Blue sheets, BoF Organizers, 5 minutes
>
> 2. Overall Scope and Problem Description: TBD, 15 minutes
>
> 3. Detailed Problem Descriptions: TBD, Max 40 minutes
>
>     3.1. Routing and tunneling
>
>     3.2. Preventing blind attacks
>
>     3.3. Protocols that do not utilize ports (ICMP, 6to4, ...)
>
>     3.4. Fragmentation
>
>     3.5. Protocols embedding IPv4 addresses
>
>     3.6. Applications assuming uniqueness of IPv4 address /
> that do not allow simultaneous usage of a resource multiple
> times from the same IPv4 address
>
>     3.7. Server applications on shared-address hosts
>
>     3.8. Support for multicast
>
>     3.9. Integrating with other existing transition methods
> (e.g. DS-Lite)
>
> 4. Overview of solution proposals on table, TBD, 20 minutes
>
> 5. BoF Proposal Discussion, All, 20 minutes
>
> 6. Decision on proceeding to WG chartering discussion or on
> turning BOF into non WG-forming BOF
>
> 7. Charter discussion, All, 20 minutes
>
> 8. Summary, Next steps : TBD, 10 minutes
>
> Reading List (to be updated as new draft (revisions) are submitted):
>
>     *
> http://tools.ietf.org/internet-drafts/draft-levis-behave-ipv4-
> shortage-framework
>     * http://tools.ietf.org/html/draft-ymbk-aplusp
>     * http://tools.ietf.org/html/draft-boucadair-port-range
>     *
> http://tools.ietf.org/html/draft-bajko-v6ops-port-restricted-i
> paddr-assign
>     * http://tools.ietf.org/html/draft-boucadair-dhc-port-range
>     *
> http://tools.ietf.org/html/draft-boucadair-behave-bittorrent-portrange
>     * http://tools.ietf.org/html/draft-arkko-townsley-coexistence
>     * http://tools.ietf.org/html/draft-despres-sam
>
>
> Background and Motivation:
> --------------------------
>
> As the IPv4 exhaustion draws nearer and happens, it will not
> be always possible to allocate hosts with public IPv4 addresses.
>
> While IPv6 is the long-term solution, IPv4 connectivity needs
> to be provided for hosts and applications unable to utilize
> IPv6 and/or require NATless IPv4 connectivity. This can
> happen for example when:
>
>     * a host is provided with IPv6 only connectivity by
> access network, but it is running (legacy) applications
> requiring NATless IPv4 connectivity
>     * a distribution of NAT to edges instead of core is
> desired e.g. for better end-user control of NAT or for
> distribution of NAT function
>
> In IETF multiple IPv6 transition solutions have been and are
> being worked on, including protocol translation that is
> worked on behave WG and Dual-Stack Lite that is worked on
> softwire WG. This BOF proposes new work on:
>
>     * defining complementing, _not competing_, model for
> shared IPv4 addresses
>     * documenting the deployment scenarios where usage of
> such addresses is envisioned and beneficial over other
> solutions being standardized
>     * defining protocol for assigning and routing shared IPv4
> addresses.
>     * documentation of the benefits, dangers, and drawbacks
> of shared IPv4 addresses
>
> As the IPv4 address exhaustion is already close, the working
> group shall develop these solutions during 2010.
>
> Prior Activity:
> ----------------
>
> IPv6 transition mechanisms have a long history.
> Port-restricted IPv4 addresses as a solution approach have
> been discussed during 2008 at least in IETF#72, IETF#73, and
> to lesser extent in v4v6 interim meeting held in Montreal:
>
> IETF#73
>
>     * Softwires WG: https://www.ietf.org/proceedings/08nov/index.html
>     * Behave WG: https://www.ietf.org/proceedings/08nov/index.html
>
> IPv4-IPv6 Co-Existence Interim
>
>     * http://trac.tools.ietf.org/area/int/trac/wiki/v4v6interim
>
> IETF#72
>
>     * intarea: https://www.ietf.org/proceedings/08jul/index.html
>     * v6ops: https://www.ietf.org/proceedings/08jul/index.html
>
> Proposed Work:
> --------------
>
> The proposed shara working group will focus on following
> topics relevant for port restricted IPv4 addresses:
>
>     * Problem statement and requirement document: a document
> describing the problem why shared IPv4 addresses are needed,
> what requirements solutions need to fulfill, and what issues
> can arise from introduction of the shared address concept
>
>     * Deployment scenarios: a document describing deployment
> scenarios where shared IPv4 addresses are applicable (e.g.
> integration with Dual-Stack Lite, point-to-point physical
> links, distributing Carrier Grade NAT, IP mobility protocols
> etc), describing and providing solutions to the problems it
> creates (e.g. port spoofing, ICMP handling, fragmentation,
> routing, tunneling, etc)
>
>     * Shared address assignment: a document describing
> mechanisms for assigning shared IPv4 addresses for hosts
>
> Approximate Timeline for Deliverables:
> --------------------------------------
>
>     * April 2009 WG approved by IESG
>     * 2H09 Submit problem statement I-D to IESG
>     * 1H10 Submit address assignment I-D to IESG
>     * 2H10 Submit deployment scenarios I-D to IESG
>     * 2H10 Recharter or close WG
>
> --
>
> Best regards,
>
>         Teemu
>
> _______________________________________________
> shara mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/shara
>
_______________________________________________
shara mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/shara

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 30 Jan 2009 11:45:41 +0100

> I'd love to see opinions from still more people reading this list.

Yes,

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

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?

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------
_______________________________________________
shara mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/shara

---

From: <[email-masked]>
Date: Fri, 30 Jan 2009 13:34:33 +0100

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