Subject: [shara] Problem statement

From: Magnus Westerlund <[email-masked]>
Date: Tue, 27 Jan 2009 13:44:33 +0100

Hi,

I would like to see a better Problem Statement for SHARA. I already
gotten questions about the problem statement. I can kind of guess having
been involved in the discussion of the related work. But I think there
is need for a collected problem statement for SHARA.

This also relates to a question that needs to be answered i a good way
to enable chartering. Why the problem scope and intended solution
proposed? I interpreted Pierre Levis' comments that there clearly are
other solutions and what about them. From my perspective as an AD I
don't think "let all flowers bloom" is the answer to the IPv4-Ipv6
coexistence and migration issues. We are here to provide recommended
solutions within a reasonable time frame so that it actually can impact
the market. We don't have forever here, and that is why dual-stack lite
was chartered, what appeared to be a reasonable solution and one which
we can think IETF can finish documenting this year.

So is what SHARA proposes necessary, a sufficient improvement, resolve
previously non-handled issues? Should we do it now or focus on first
completing the already chartered items in Softwire and Behave?

For your knowledge, I need most of these answers quickly. The IESG and
IAB have their call to discuss the BOFs next Thursday. By then I need to
know as much as possible to have the right discussion about this BOF
proposal's approval or not.

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: Olaf Maennel <[email-masked]>
Date: Tue, 27 Jan 2009 15:01:52 +0200

Hi, 

could section 1 and 1.1 from our tech-report (see
http://mice.cs.columbia.edu/getTechreport.php?techreportID=560) serve as a
beginning for this problem statement? or should it better come from a
different direction?

    olaf

---

From: <[email-masked]>
Date: Wed, 28 Jan 2009 00:25:46 +0100

Hi Olaf,

I think what SHARA should be intended to is:

a) develop methods for port-restricted IPv4 address allocation (using dhcp, ipcp, dsmip, mip4, proxy-mip, whatelse), as a new/additional method for transition to IPv6

b) develop solutions for the problems a shared IPv4 address creates: fragmentation, routing, tunneling, lack of port randomization, etc.

c) usage of port restricted IP address to improve network architectures (distributed NATs instead of CGNs, etc)

The link you sent together with your document (draft-ymbk-aplusp-02.txt) provide solutions for some of the issues listed in b) and c) above, but that is part of the solution space instead of the problem statement.

If the above points are acceptable, we can work on charter text based those points and come up with text during this week.

- gabor

  >-----Original Message-----
  >From: [email-masked] [mailto:[email-masked]] On Behalf Of
  >ext Olaf Maennel
  >Sent: Tuesday, January 27, 2009 5:02 AM
  >To: Magnus Westerlund
  >Cc: [email-masked]
  >Subject: Re: [shara] Problem statement
  >
  >
  >Hi,
  >

---

From: Matthew Ford <[email-masked]>
Date: Tue, 27 Jan 2009 23:52:21 +0000

Hi all,

> b) develop solutions for the problems a shared IPv4 address creates: fragmentation, routing, tunneling, lack of port randomization, etc.

If there were easy solutions for all the issues created by widespread 
deployment of shared IPv4 addresses, we wouldn't need IPv6.

I think an important work item to add to the charter is documentation of 
as many of the issues that shared IPv4 addresses create that can be 
identified by the community at the time. Shared addresses may (or may 
not) be necessary but they should come with a health warning.

I can offer cycles to work on this.

Mat

---

From: Randy Bush <[email-masked]>
Date: Wed, 28 Jan 2009 13:39:26 +0900

> a) develop methods for port-restricted IPv4 address allocation (using
> dhcp, ipcp, dsmip, mip4, proxy-mip, whatelse), as a new/additional
> method for transition to IPv6
>
> b) develop solutions for the problems a shared IPv4 address creates:
> fragmentation, routing, tunneling, lack of port randomization, etc.
>
> c) usage of port restricted IP address to improve network
> architectures (distributed NATs instead of CGNs, etc)

i like "address sharing" as opposed to specifying using port number. 
there are a few folk thinking of stealing bits from the ip frag ident 
number instead.

i am neither advocating nor dissing this idea.  just trying to leave 
room for it.

randy

---

From: <[email-masked]>
Date: Wed, 28 Jan 2009 05:39:32 +0100

>From: ext Matthew Ford [mailto:[email-masked]]
  >Sent: Tuesday, January 27, 2009 3:52 PM
  >To: Bajko Gabor (Nokia-CIC/MtView)
  >Cc: [email-masked]; [email-masked];
  >[email-masked]

Good point to add. The intention is to emphasize that this solution is a temporary one to be used during the transition period, and not an alternative to IPv6 (not even on the short term).

  >I can offer cycles to work on this.

Thanks, your input is needed and appreciated.
- gabor

---

From: <[email-masked]>
Date: Wed, 28 Jan 2009 13:54:21 +0100

Hi,

I've just submitted the following draft that could be valuable information for shara chartering:

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : IPv4 Shortage Framework
	Author(s)       : P. Levis, et al.
	Filename        : draft-levis-behave-ipv4-shortage-framework-00.txt
	Pages           : 15
	Date            : 2009-01-28

This document analyses the main issues related to IPv4 Internet
access in the context of public IPv4 address exhaustion.  It would be
valuable to assess each IPv4 address shortage solution with all these
issues, to check to what degree they are concerned, how they handle
each issue, and to what extent they resolve the pending problems.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-levis-behave-ipv4-shortage-framework-00.txt

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] 
> De la part de [email-masked]
> Envoyé : mercredi 28 janvier 2009 05:40
> À : [email-masked]
> Objet : Re: [shara] Problem statement
> 
> 
> 
> Good point to add. The intention is to emphasize that this 
> solution is a temporary one to be used during the transition 
> period, and not an alternative to IPv6 (not even on the short term).
>