Subject: [shara] Updated BOF proposal

From: <[email-masked]>
Date: Thu, 29 Jan 2009 16:26:33 +0100

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

---

From: <[email-masked]>
Date: Fri, 30 Jan 2009 07:23:05 +0100

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:
> --
>     3.6. Applications assuming uniqueness of IPv4 address / 
> that do not allow simultaneous usage of a resource multiple 
> times from the same IPv4 address
> 
>     * 
> http://tools.ietf.org/internet-drafts/draft-levis-behave-ipv4-
> shortage-framework
>     * 
> http://tools.ietf.org/html/draft-bajko-v6ops-port-restricted-i
> paddr-assign
>     * 
> http://tools.ietf.org/html/draft-boucadair-behave-bittorrent-portrange
> 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:
> 
>     * documenting the deployment scenarios where usage of 
> such addresses is envisioned and beneficial over other 
> solutions being standardized
> 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
> 
> 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
>