Subject: changes to draft-ietf-v6ops-nat64-pb-statement-req-00.txt

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 17 Jul 2008 16:48:43 +0200

Hi,

I am trying to extract the actual proposed changes for the draft

------------------------------------------
- 1) Additional scenario needed?
------------------------------------------

It seems that there is the potential need for a new scenario.
It is the case described by Dan and by Teemu about a dual stack host, 
located in a v6 network, and that needs to run a v4 only application. In 
order to do that, it needs to obtain a public IPv4 transport address and 
also discover a tunnel endpoint, so it can tunnel v4 packets in v6 till 
the tunnel endpoint and use the IPv4 transport address it has obtained 
to establish a communication with v4 land.

So essentially this is tunnel scenario, but rather than being obtaining 
a full IPv4 address to use, the host only obtains a transport address 
(which is public)

I understand that this is what Dan and Teemu are proposing, is that correct?

So, if this is the case, how can we fit this into the document?

As i see it, the document has two parts, clearly differentiated:
A first part that covers an overview of the different aspects of 
transition and then a part that described the specific requirements of 
new translation mechanism

I think that it makes sense to me to include a description of this case 
in the overview section.

In order to do that, we need first to ackwoledge the exsitance of a new 
scenarion in section

2.1.  Transition scenarios

currently, it includes 6 scenarios:

There are six obvious transition scenarios:

   o  IPv4 system connecting to an IPv4 system across an IPv4 network,
   o  An IPv6 system connecting to an IPv6 system across an IPv6
      network,
   o  an IPv4 system connecting to an IPv4 system across an IPv6
      network,
   o  an IPv6 system connecting to an IPv6 system across an IPv4
      network,
   o  an IPv4 system connecting to an IPv6 system, or

   o  an IPv6 system connecting to an IPv4 system.

I understand that we need to include one more:

   o  a dual stack system connected to a IPv6 domain that is connecting to an IPv4 system.

In addition, we need to include an additional text in section

2.1.2.  Transition scenarios that do not require translation

something along these lines:

Another scenario that does not involves translation is the case
where a dual stack node is connected to an IPv6-only domain
and it is communicating with a IPv4-only node as depicted in Figure 2.

                      ,-----.                 ,-----.
                    ,'       `.             ,'       `.
                   /           \           /           \
                  /   IPv6-only \         /   IPv4-only \
                 /    Domain   +-----------+  Domain     \
                ;              |    Tunnel |              :
                |              |  endpoint |              |
                :     +-----+  +-----------+              ;
                 \    |Dual |    /       \     +----+    /
                  \   |Stack|   /         \    |IPv4|   /
                   \  |Host |  /           \   |Host|  /
                    `.+-----+,'             `. +----+,'
                      '-----'                 '-----'

In this case, the dual stack host needs to establish a IPv4 in IPv6 
tunnel to the tunnel endpoint. In addition to that, the dual stack
needs to obtain a IPv4 address that is valid in the IPv4-only domain.
The simplest option is for the dual stack to obtain an IPv4 public
address. However, this may not be possible due to the shortage of
IPv4 public addresses. The other option is to use an IPv4 private address
(and potentially in conjunction with IPv4 NAT). The other option
is for the dual stack to obtain a public IPv4 transport address.
In all the cases, the acquisition of the address can be performed dynamically.

would this address your inputs?

----------------------------------------
-2) Scalability
----------------------------------------

Teemu proposed to include:

2.2.  Requirements for the overall transition strategy

8.  Transition architectures should be scalable for large number of
hosts and high data speeds.

4.2. Important things that SHOULD be supported

I9: Scalability

The translation mechanism SHOULD support very large number of hosts and
high data speeds with reasonable infrastructure requirements considering
equipment available at the transition timeframe.

I think this makes sense, and i have a hard time finding someone who don't agrees with this
so i am planning
 to include them

--------------------------------------------
-3) discovery
---------------------------------------------

Teemu also porposed:

2.2.  Requirements for the overall transition strategy

9.  Availability of transition solutions on an access network should be
quickly discoverable.

4.2. Important things that SHOULD be supported

I10: Discovery

The translation mechanism SHOULD be quickly discoverable, preferably in
one RTT, to help moving hosts better assess capabilities of available
access networks and to provide good user experience.

I have a hard time understanding this one.
I mean R1 states:

   R1: Changes in the hosts

   The translation mechanism MUST NOT require changes in the v4-only
   nodes to support the Basic requirements described in this section,
   unless explicitly stated in the particular requirement.  The
   translation mechanism MAY require changes to v6-only nodes.

So if we don't want changes in the host, how can a host have the discovery mechanisms? I mean, 
i think this assuming some other form of solution that is not based on translation.

I am not doing anything about this at this point

------------------------------------------
-4) no translation
------------------------------------------

Teemu also porposed:

4.3. Important things that MAY be supported

M1: No NATs or ALGs

The translation mechanism MAY avoid use of IPv4 NATs and thus also avoid
need for ALGs. 

this clearly seems contradictory in a requirements fro translation (no translation)

I understand that translation should be avoided and we already say this in the document
i.e. that dual stack is preferred and then tunnel and finally if there is no other option
translation. I don't think that this should go in the requirements section cause seems like
and oxymoron to me

------------------------------------------
-5) MIP6 support
------------------------------------------

George and Jaru commented that I5: MIPv6 support
should go away
I am removing that

------------------------------------------
-6) Symbian 
------------------------------------------
added symbian to the OS in market timing 
consdierations

regards, marcelo

---

From: Alain Durand <[email-masked]>
Date: Thu, 17 Jul 2008 11:07:04 -0400

> I am trying to extract the actual proposed changes for the draft

How is this different from the dual-stack lite mechanism? See
draft-durand-dual-stack-lite-00.txt, section 3.2

Second question, if you have that, why is it not enough and why would you
still need to do any IPv6 to IPv4 translation?

  - Alain.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 17 Jul 2008 17:29:31 +0200

> draft-durand-dual-stack-lite-00.txt, section 3.2
I don't know
I am working on the requirement draft, not on solution space.
So do you think we need to include this in the req draft or not?

> still need to do any IPv6 to IPv4 translation?
well, it seems that you will be having legacy IPv6 hosts (i.e. no new 
mechanisms) that are running IPv6 apps that want to communicate with v4 
hosts that are running ipv4 apps and in that case, this doesn't seem to work

regards, marcelo

---

From: Alain Durand <[email-masked]>
Date: Thu, 17 Jul 2008 11:35:46 -0400

> So do you think we need to include this in the req draft or not?

Well, I'm not sure. If you are talking about the requirement for a NAT
v6->v4, then I would say no, but add a pointer to my draft.

> hosts that are running ipv4 apps and in that case, this doesn't seem to work

The only thing that is required for dual-stack lite is a v4/v6 tunnel that
is present on most implementation I know, so no new code is needed.
And if this is still a problem, you can always use a router upstream to do
the encap for you.

  - Alain.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 17 Jul 2008 17:40:49 +0200

> v6->v4, then I would say no, but add a pointer to my draft.
it is not only a translation requirement draft
read the draft, find out  and comment :-)
> And if this is still a problem, you can always use a router upstream to do
but you would need to have v4 on your hosts, right?

the assumption for translation is that you have v6 only nodes on one side

regards, marcelo

---

From: Alain Durand <[email-masked]>
Date: Thu, 17 Jul 2008 11:54:32 -0400

> but you would need to have v4 on your hosts, right?

No, you need a v4 stack, not a v4 address. That is the whole point of the
dual-stack lite model.
 
> the assumption for translation is that you have v6 only nodes on one side

This is the part I'm challenging by making a distinction between v6-only,
dual-stack provisioned (v4 & v6) and dual-stack lite, where the host is
dual-stack capable but only provisioned with v6.

  - Alain.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 17 Jul 2008 18:00:48 +0200

> No, you need a v4 stack, not a v4 address. That is the whole point of the
i guess i will need to read the draft then cause i fail to understand 
how useful could a stack wihtout an IP address could be

regards, marcelo

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 17 Jul 2008 09:07:21 -0700

> -----Original Message-----
> From: marcelo bagnulo braun [mailto:[email-masked]] 
> Sent: Thursday, July 17, 2008 7:49 AM
> To: 'IPv6 Operations'; Fred Baker; Dan Wing; 
> [email-masked]; Brian E Carpenter; 
> [email-masked]; Rémi Després; Jari Arkko; 
> Philip Matthews
> Subject: changes to draft-ietf-v6ops-nat64-pb-statement-req-00.txt
> 
> Hi,
> 

I don't have a proposal; I just want to see if folks are prepared
to have subscribers lose existing v4 functionality for v4 hosts
accessing the v4 Internet (ALGs, NAT-PMP, and UPnP).

That is, I am trying to imagine a Behave or Softwire proposal
that I would personally be willing to buy from my ISP, could
recommend to my mother-in-law, and could recommend to my
nephew.  I don't have an XBox, so I don't personally care but I 
am aware of how XBox does UPnP IGD.  My Nephew has an XBox and
uses BitTorrent a lot more than I do.  If a BitTorrent client
cannot get v4 mapped, it will be a 'leech' and have horrid 
download speeds.  (Yes, I know most 
BitTorrent clients support v6, but I don't know how well-
exercised that code is and I don't know how many v6-capable
BitTorrent peers there are to upload to [so that download
speeds are fast]).  BitTorrent seems an a valuable use
case to consider.

The two biggest BitTorrent clients (uTorrent and Vuze 
(Azureus)) support UPnP (and NAT-PMP).  So including
support for them to do UPnP -- somehow -- would allow them 
to function well.

We could also conciously decide to not bother, and for
those subscribers that need incoming v4 connections or 
need v4-aware ALGs, they will have to stick with a "real"
v4 connection (like today).  Other subscribers can use
our transition scheme.  I just worry that reduces the
usefulnes of our transition scheme.  The question is if
leaving out UPnP IGD/NAT-PMP/v4 ALGs reduces the 
usefulness 'too much'.

> and it is communicating with a IPv4-only node as depicted in Figure 2.

Looks good to me.

I don't know how we would determine if we met the requirement,
though.  Most any of these could be implemented in the aggregation
router (the first L3 hop away from the subscriber), consuming
1 MIPS per subscriber and any of these could be implemented in 
a multi-million dollar server placed in Denver, Colorado (the 
center of the US) also consuming 1 MIPS per subscriber.  Which
solution meets that requirement better?  Or are they similar
because they're both 1 MIPS per subscriber, and this is really
a requirement around state?  Or the need for layer 7 awareness
in a protocol-sniffing ALG (which I agree does require more
processing cycles than just NATing and forwarding packets).

Or is this scalability question really about operational 
expense and operational complexity (fewer boxes with less state 
inside of them is better than many boxes with a lot of state 
inside of them)?

Was Teemu perhaps considering a situation where a v6 box is
doing the translation from a v4-host to the ISP's v6 network?
After all, such a v6 box will look like a v6 host to the
v6 network: 

  [v4 host] --- [v4/v6 Interworking] ----- [ ISP box ] --- v4 Internet
                [    CPE Device    ]

It would be useful for that v6 box to automatically sense whatever
it needs to know from the ISP's network (for example, with IVI,
it would need to know the IVI prefix).

Somewhat related to this, I would like to consider one of
my worries with ALGs:  getting bugs fixed in a massive
centralized box.

My story:  About a month
ago, ftp.ietf.org changed its behavior that broke my FTP
client (my FTP client's code was last modified in 1998).
This had nothing to do with an ALG -- I use PASV and
have my FTP ALG in my NAT turned off -- but rather just
a change in behavior to a very long-established protocol.
It is reasonable to expect that this happens elsewhere,
not just with the IETF's FTP servers, and not just with
FTP.  

If an ISP has to receive trouble-tickets from users
for the ISP's broken ALG ("it doesn't work with such-and-
such FTP client", or "it doesn't work with such-and-such
FTP server"), or has to receive trouble-tickets to add new
application support to their NAT ("why don't you support
H.323, I need it for NetMeeting and can't support my 
business clients!"), it can be a long, drawn-out process
between the vendor, the ISP, and the subscribers.

One way to reduce this problem is to leave this function
where it is today:  at the subscriber premise.  If the
subscriber needs a bugfix, or needs to tweak something,
or needs an ALG that is capable of helping them with
their fancy new protocol XYZZY, they can get a NAT (or
build a Linux NAT) that supports XYZZY -- without 
involving the ISP.  

This is one of my purposes for asking if people care about 
ALGs, UPnP, and NAT-PMP -- and why APBP could keep this
complexity to the subscriber edge (where it is now).

Thanks!
-d

---

From: Alain Durand <[email-masked]>
Date: Thu, 17 Jul 2008 12:52:47 -0400

> how useful could a stack wihtout an IP address could be

When a dual-stack lite host (dual stack capable, v6-only provisioned) wants
to send a v4 packet, it can simply put any v4 dummy address as source
address before shipping the packet through the v6 tunnel to the CGN. Even
0.0.0.1 will work as it will be replaced later by the CGN. The mapping will
be disambiguified by the tunnel ID (v6 src address).

  - Alain.

---

From: Rémi Després <[email-masked]>
Date: Fri, 18 Jul 2008 12:53:47 +0200

>   o  a dual stack system connected to a IPv6 domain that is connecting 

Approved.

> and it is communicating with a IPv4-only node as depicted in Figure 2.

After "...  shortage of IPv4 public addresses." you could add:
"The other option is to obtain an IPv4 public address with a limited 
range of usable ports."

> So if we don't want changes in the host, how can a host have the 
> discovery mechanisms? I mean, i think this assuming some other form of 
> solution that is not based on translation.
> 

Proposal (additions between "s):
The translation mechanism SHOULD be quickly discoverable, preferably in 
one RTT, to help moving "dual stack" hosts "or router CPEs" better 
assess capabilities of available access networks and to provide good 
user experience.

Proposal:

M1: No NATs or ALGs "between dual stack and IPv4 hosts"

The translation mechanism MAY avoid use of IPv4 NATs and thus also avoid 
the need for ALGs "(translation being then limited, for example, to 
encapsulation-decapsulation).

Regards.

Rémi

---

From: Jari Arkko <[email-masked]>
Date: Fri, 18 Jul 2008 15:34:27 +0300

Marcelo,

I agree with your assessment of issues 3 through 5.

Jari

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 19 Jul 2008 16:30:43 +0200

Hi Dan,

> That is, I am trying to imagine a Behave or Softwire proposal
this is the only thing from your perspective that somehow confuses me
I think that there are several different problems and different 
scenarios and that these should be addressed
with potential different tools

I mean, it is the same for the IPv4 case, one thing is a NAT box, which 
solves some problem and a different thing is IPnP protocol that 
addresses other issues. Of course they complement each other or one is 
build on top of the other, but they were conceived differently

So, so far, the goal is to identify different useful scenarios and then 
try to find requirements for those and then solutions

We had initially identified two sceanrios, one the v4 - v6- v4 case and 
another one that was the IPv6 only host communicating to the IPv4 only 
only host

Now, there is another scenario, which is the IPv4 only app running on an 
IPv6 only node that needs to communicate to the v4 peers.
To me what makes sense is to find solutions for these different problems

I guess that what i am trying to ask you (in a very convoluted way) is 
whether you think we should mix all these scenarios and address them all 
toghether or do you think that hiving different scenarions, with 
different tools and then figuring out potential synergies (i.e. my 
understanding of the current approach) makes sense

If you think this makes sense, then we should include the 3 scenarios in 
this draft

BTW, One may also think that this draft is kind of weird, in the sense 
that it identifies the 3 scenarios mentioned above and then only defines 
the requirements for one of them, i.e. the one requiring translation.
 From a document perspective, we can do 3 things, i guess.
Either we keep it as it is, even if it may seems somehow strange.
Or we split in two documents, one as the overview of the scenarios and 
another one with the requirements for translation, (and eventually 
having two more documents with requirements for the other scenarios,
or we add to this document the requiremetns for the other scenarios)

I personally preffer the first or the second one, since i would like to 
wrap up the transalion requireemtns asap.

>> would this address your inputs?
ok, i will add this

> though.
:-)

right

(it is like the usual incremental deployment requriement , it means 
completely different things to different people)

Well, i think Yakov defined scalability as the growth in the resources 
needed is lees than linear with the number of users, or something  in 
this lines

So, in this case, we could try to apply this definition here, but i am 
not sure we want to go that far?
>   Most any of these could be implemented in the aggregation
imho, people usually tries to take scalabilty anytime they look into a 
solution, so it is alsways present. Inlcuding it simply makes it explicit.
For instance, in the last example you mention, when a solution requires 
more state, it ususally is more complex and people will preffer the 
other solution (even if we include this req or not)

I am perfeclty ok leaving this out, but as i say, i think it is common 
sense that people will have this in mind
OTOH, it is true that may not be so straight forward its application in 
the different scenarios.

> it would need to know the IVI prefix).
but this is not the translation scenario, but a tunnel scenario, right?
So we are not defining requiremetns for this sceanrio (at least not in 
the current document)

If we decide we should define requirements for these, i am for including 
this, but for the requrieemtns for trasnaltion, i think this doesn't 
apply and should not be included, agree?

> complexity to the subscriber edge (where it is now).
I think i understnad your point, not sure i can transalte it into a 
requirement for the translation case....

Do you think that we should split the requirement one for CPEs NATs and 
another one for carrier grade nats and allow ALGs in CPE nats and avoid 
them in carrier grade nats?

would that make sense to you?

regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 19 Jul 2008 16:38:36 +0200

>> connecting to an IPv4 system.
gee, thanks for approving it

> "The other option is to obtain an IPv4 public address with a limited 
this is already implicity in the IPv4 transport address part

>> discovery mechanisms? I mean, i think this assuming some other form 
>> of solution that is not based on translation.
>>
> The translation mechanism SHOULD be quickly discoverable, preferably 
> in one RTT, to help moving "dual stack" hosts "or router CPEs" better 
again, this doesn't apply to the translation case, but the second tunnel 
case that we are now including,

so this should be included in wherever we decide to make a list fo the 
requirements for these other scenarios

> The translation mechanism MAY avoid use of IPv4 NATs and thus also 
> avoid the need for ALGs "(translation being then limited, for example, 
> to encapsulation-decapsulation).
>
again, this doesn't belong to the translation case but to the other 
tunnel case

regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 19 Jul 2008 17:30:16 +0200

> be disambiguified by the tunnel ID (v6 src address).
i see
clever, indeed

I have read the draft (at least parts of it)

You state that:

   o  Dual-stack lite does not require any hack to the DNS.  In other
      words, there is no need to synthesize fake AAAA records to
      represent IPv4 addresses.  This make DNSsec works more reliably.

   o  Because of the DNS ALG hack, NAT-PT places restriction on the
      topology, in most cases requiring that all exiting traffic go
      through a single point of contention.  Because there is no DNS ALG
      with dual-stack lite and because each dual-stack lite device can
      be directed independently to a different dual-stack lite NAT, the
      dual-stack lite architecture can scale better.

While this was true for nat-pt and to some degree for nat64, if we adopt 
Dave's suggestion of using the v4 mapped prefixes, this all go away i 
think cause there is no relationship whatdoever between the dns64 and 
the nat64

As long as you recieve a AAAA RR from somehwere, the nat64 can be placed 
in a completely different part of the topology and the actual data 
packets do not need to use the same path than the DNS query/repsonse did

So, i think this is no longer true

Regards, marcelo

---

From: "[email-masked]" <[email-masked]>
Date: Mon, 21 Jul 2008 09:03:18 +0300

Hi, 

>From: ext marcelo bagnulo braun [mailto:[email-masked]] 
>Sent: 17 July, 2008 17:49

>So essentially this is tunnel scenario, but rather than being 
>obtaining a full IPv4 address to use, the host only obtains a 
>transport address (which is public)

The solution can be tunneling, but also also double translation (4->6->4) as described at least in NATv4v6v4 and MNAT-PT drafts.

>connecting to an IPv4 system.

Well yes, but then again isn't that essentially the same as having two of those six obvious scenarios simultaneously at play (v6 connecting to v6 across v6, and v4 connecting to v4 across v6). 

>From those six, other scenarios could be build as well, such as dual-stack connected to IPv4 domain that is connecting to IPv6 system, or dual-stack connected to dual-stack domain contacting to dual-stack systems (as already described in chapter 2.1.1).

Could it be put this way:"A network can have a combination of the obvious transition scenarios simultaneously in play. An example of such a scenario is an IPv4/IPv6 dual-stack system connecting to an IPv4 system across an IPv6 network."? 

>would this address your inputs?

Yes. Though there might be other options as well: shared IPv4 address, dual-stack lite (if I got it right)? Nevertheless, all are essentially IPv4 in IPv6 tunnel. Maybe the requirement document should be more vague about how to actually get the IPv4 address from tunnel endpoint (and which kind, or none)?

One related question: what happened to discussions of doing IPv4->IPv6 translation on the host and then IPv6->IPv4 on the translation gateway?

>so i am planning to include them

I agree that this is not easily measurable, but I proposed this as for me it seems that various solutions around have different requirements for states, cycles, complexities, and it would be good if the solution proposals would have some considerations written down. E.g. tunneling-based solution that uses IPsec would have different requirements for tunnel endpoint than non-IPsec solution.

>i think this assuming some other form of solution that is not 

Well v4-only nodes must remain unchanged and I agree that it is desirable that changes for v6-nodes would not be needed, but I would not rule out solutions that does require v6-node changes if so doing provide (clearly) better functionality than the solutions that do not involve v6-nodes changes. Couldn't an operator be running two kinds of solutions: one that helps transition of those unchangeble IPv6-nodes that are out there already, and improved one that provides better transition for modified nodes? 

Furthermore, if multiple solutions are standardized, how a v6-node attaching to a network knows what solutions are being available there (unless of course all standardized solutions are invisible to v6-nodes)?

True, it was my confusion (with general requirements I am thinking about transition commented on wrong place). 

Thank you.

Best regards,

	Teemu

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 21 Jul 2008 11:20:04 +0200

Rémi Després escribió:
> marcelo bagnulo braun  - Le 7/19/08 4:38 PM :
>> Rémi Després escribió:
>
>>>>
>>>>                      ,-----.                 ,-----.
>>>>                    ,'       `.             ,'       `.
>>>>                   /           \           /           \
> Not quite: a Transport address cannot IMU be considered equivalent to 
> an address plus A RANGE of ports.
>
> (This additional alternative is part of draft-despres-v6ops-apbp-01.)
>
> New proposal to actually cover the point: after "transport address", 
> add "or a public IPv4 address plus a limited range of ports".
>
>
>>> in one RTT, to help moving "dual stack" hosts "or router CPEs" 
>>> better assess capabilities of available access networks and to 
>>> provide good user experience.
>>>
>>>
>> again, this doesn't apply to the translation case, but the second 
>> tunnel case that we are now including,
>
>> so this should be included in wherever we decide to make a list fo 
>> the requirements for these other scenarios
>
> Is there a reference to see how this tunnel case is introduced?
yes, i have included the text that i have mentioned above, describing 
this scenario

---

From: Rémi Després <[email-masked]>
Date: Mon, 21 Jul 2008 11:03:51 +0200

> this is already implicity in the IPv4 transport address part

Not quite: a Transport address cannot IMU be considered equivalent to an 
address plus A RANGE of ports.

New proposal to actually cover the point: after "transport address", add 
"or a public IPv4 address plus a limited range of ports".

Regards.

Rémi

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 21 Jul 2008 13:22:44 +0200

> The solution can be tunneling, but also also double translation (4->6->4) as described at least in NATv4v6v4 and MNAT-PT drafts.
but we are not reccomending that, right?

i mean this document is supposed to be a reccomednation, and the point 
is that is not what we reccomend afaiu

> Could it be put this way:"A network can have a combination of the obvious transition scenarios simultaneously in play. An example of such a scenario is an IPv4/IPv6 dual-stack system connecting to…
that is why it says simple sceanrios :-)

i mean, i certainly see we can come up with very complex scenarions with 
a combination of all this. the question is whether we think these are so 
relevant to be explicitly mentioned. I think the rpevious ones are the 
basic ones and the others can be elaborated from these

> Yes. Though there might be other options as well: shared IPv4 address,
this is what i meant by getting a v4 transport address, right, they 
share the v4 address and demux based on prtos

>  dual-stack lite 
dual stack lite is the tunneling mechanisms

> (if I got it right)? Nevertheless, all are essentially IPv4 in IPv6 tunnel. Maybe the requirement document should be more vague about how to actually get the IPv4 address from tunnel endpoint (and which kind, or none)?
>   
right i can try to add a sentence on this

> One related question: what happened to discussions of doing IPv4->IPv6 translation on the host and then IPv6->IPv4 on the translation gateway?
not sure what you mean

> I agree that this is not easily measurable, but I proposed this as for me it seems that various solutions around have different requirements for states, cycles, complexities, and it would be good i…
right i have kept this one in any case

> Furthermore, if multiple solutions are standardized, how a v6-node attaching to a network knows what solutions are being available there (unless of course all standardized solutions are invisible t…
ok, so we can say that we need to be discoverable for v6 nodes if they 
require updating

regards, marcelo

---

From: Rémi Després <[email-masked]>
Date: Mon, 21 Jul 2008 16:35:58 +0200

> wrap up the transalion requireemtns asap.

Marcello,

You have well clarified where there is a short term problem, which 
explains some of our previous mail exchanges.

Since the document deals  with requirements only for v4-v6 translation 
mechanisms, what about making it clear in the title, e.g.:

"Pv4/IPv6 Coexistence - Requirements for solutions based on IPv4-IPv6 
translations".

Regards.

Rémi

---

From: <[email-masked]>
Date: Tue, 22 Jul 2008 15:46:42 +0300

>> The solution can be tunneling, but also also double 
>translation (4->6->4) as described at least in NATv4v6v4 and 
>MNAT-PT drafts.
>>   

Right. 

I'm looking forward to see the next version of the draft.

	Teemu

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 23 Jul 2008 11:04:04 +0200

Rémi Després escribió:
>> BTW, One may also think that this draft is kind of weird, in the 
>> sense that it identifies the 3 scenarios mentioned above and then 
>> only defines the requirements for one of them, i.e. the one requiring 
>> translation.
>> Or we split in two documents, one as the overview of the scenarios 
>> and another one with the requirements for translation, (and 
>> eventually having two more documents with requirements for the other 
>> scenarios,
>> I personally preffer the first or the second one, since i would like 
>> to wrap up the transalion requireemtns asap.
>
> Marcello,
>

cause due the dual nature of the document, the current tittle actually 
fits the first part of the doccment

> gards.

---

From: Rémi Després <[email-masked]>
Date: Wed, 23 Jul 2008 12:12:28 +0200

> fits the first part of the doccment

  Yes, exactly.

  The first part is about scenarios, all of them, and the second part is 
about requirements, but only for NAT64 based solutions.
  "IPv4/IPv6 Coexistence and Transition: Requirements for solutions", 
suggests that all solutions have their requirements covered, which is 
misleading.

  Including requirements for other solutions would solve the problem, 
but your legitimate wish to wrap up asap makes it unrealistic.

  Examples of others title that IMO would fit:

  "IPv4/IPv6 Coexistence scenarios - Requirements for v4-v6 translation 
  mechanisms"

  "IPv4/IPv6 Coexistence scenarios - Requirements for NAT64 based solutions"

  Note that updating the title doesn't imply a change of the file-name 
(draft-ietf-v6ops-nat64-pb-statement-req-0x is OK).

  Regards

RD