Re: [shara] Updated BOF proposal

[<[e-mail]>]

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 [e-mail]" <[e-mail]>
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 : [e-mail] [mailto:[e-mail]]
> De la part de [e-mail]
> Envoyé : jeudi 29 janvier 2009 16:27
> À : [e-mail]
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/shara
>
_______________________________________________
shara mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/shara