Subject: How to include APBP scenarios in the Coexistence Requirement I-D

From: Rémi Després <[email-masked]>
Date: Thu, 19 Jun 2008 16:45:43 +0200

Hi Marcello,

You may not remember my e-mail of may 22:
http://www.ops.ietf.org/lists/v6ops/v6ops.2008/msg00808.html,

It dealt with the relationship between
- my draft-despres-v6ops-apbp-00 (APBP)
- your draft-ietf-v6ops-nat64-pb-statement-req-00

Since the matter of the APBP I-D fits in the scope of your Requirement 
I-D, I take the opportunity of a reminder to (hopefully) clarify the 
subject.

Your Requirement draft is about
  "IPv4/IPv6 Coexistence and Transition: Requirements for solutions".
Its scope, defined in the introduction, is:
  "requirements for solutions to IPv4/IPv6 coexistence and eventual
transition in a scenario in which dual stack operation is not the norm"
It includes, among others, scenarios for:
A. "an IPv4 system connecting to an IPv4 system across an IPv6
network"
B. "an IPv6 system connecting to an IPv4 system".

Now, in the APBP draft:
- Section 2 introduces a new scenario for A.
- Section 5.2 introduces a new scenario for a variant of B (where the
IPv6 system is modified to obtain E2E IPv4 transparency for IPv4/IPv6
encapsulated packets)

The purpose of these new scenarios is:
- Scalability (scenario A)
- E2E transparency (scenario B)

To introduce visibility of these scenarios in your draft without too 
much reorganization, I suggest this possibility:

In your I-D,
  " 2.1.2 Scenarios that do not require translation
    2.1.3 Scenarios that require translation "
would be replaced by:
  " 2.1.2 Scenarios that do not require translation between IPv6 and IPv4
      2.1.2.1 Scenarios based only on tunnels
              <current 2.1.2 text>
      2.1.2.1 Scenarios combining tunnels and address-port borrowing
	     < A text, not too long, I could volunteer to provide >
    2.1.3 Scenarios that require translation between IPv6 and IPv4
              <current 2.1.3 text > "

The questions are then:
- Is it agreed that something needs to be done? (And if not, what 
objections need to be discussed)
- If it is agreed, are there better ways to include APBP scenarios in 
the Requirement I-D?

Regards.

Rémi

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 19 Jun 2008 17:56:11 +0200

Remi,

as editor of the document, my task is to reflect the WG consensus in the 
document.
So far, i only see you supporting for this i.e. i haven't received any 
other comment on this respect.

So, if other people care to comment on this, and the WG express that 
they are ok with including this in the document, i would do that.

Regards, marcelo

---

From: Rémi Després <[email-masked]>
Date: Thu, 19 Jun 2008 19:48:52 +0200

> as editor of the document, my task is to reflect the WG consensus in the 

Fair enough.

> they are ok with including this in the document, i would do that.

Please remember what Teemu Savolainen wrote to you in
http://psg.com/lists/v6ops/v6ops.2008/msg00800.html, namely:

"One aspect on these transition mechanisms is placement of NAT(s) (4-4, 
4-6, 6-4) and required ALGs, i.e. whether those are on client itself, on 
gateway, or nowhere (APBP kind of approach). Different approaches have 
different pros and cons, which should be studied more. The placement 
likely affects at least on scalability of the solution."

Also you can note what Brian Carpenter answered to Iljitsch van Beijnum, 
in http://www.ops.ietf.org/lists/v6ops/v6ops.2008/msg00876.html, namely:

 > The public address of the NAT to which you are tunneling. Of course,
 > that NAT has to be configured to forward port N through a tunnel
 > to whatever IPv4 address 2001:db8:31::1 has borrowed.
 >
 > (draft-despres-v6ops-apbp-00.txt would automate the borrowing
 > process, if you don't want to configure it.)

Automating configuration is of course a nice thing to have.

Rémi

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 19 Jun 2008 19:59:40 +0200

In the next version, i will try to reflect the received comments indeed

Rémi Després escribió:
>> as editor of the document, my task is to reflect the WG consensus in 
>> the document.
>
> Fair enough.
>
>> So far, i only see you supporting for this i.e. i haven't received 
>> any other comment on this respect.
> >
> "One aspect on these transition mechanisms is placement of NAT(s) 
> (4-4, 4-6, 6-4) and required ALGs, i.e. whether those are on client 
> itself, on gateway, or nowhere (APBP kind of approach). Different 
> approaches have different pros and cons, which should be studied more. 
> The placement likely affects at least on scalability of the solution."
>
>
>
> Also you can note what Brian Carpenter answered to Iljitsch van 
> Beijnum, in 
> http://www.ops.ietf.org/lists/v6ops/v6ops.2008/msg00876.html, namely:
>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 20 Jun 2008 09:54:09 +1200

>> process, if you don't want to configure it.)

There's also draft-cheshire-nat-pmp of course. I think
this can be included as an open question in the requirements
draft, and the discussion is probably broader than just v6ops.

   Brian

---

From: Rémi Després <[email-masked]>
Date: Fri, 20 Jun 2008 09:16:11 +0200

> draft, and the discussion is probably broader than just v6ops.

Thanks a lot.
I had missed this important one!

Its scope does differ from that of APBP in that:
- its NAT-PMP deals with port mappings *in NAT devices*
- APBP deals with address-port borrowing from APBP servers where *NATs 
are avoided* (IPv4 packets can be just encapsulated and decapsulated).

I plan to study the NAT-PMP draft in details, and hopefully identify how 
much of it can be extended or adapted to the scope of APBP.

Where a "broader" discussion could start is an interesting question.
So far, v6ops seemed to me the best fit, but any other decision would be 
fine.

Regards.

Rémi