Subject: Re: [BEHAVE] Plan for IPv4/IPv6 translation documents

From: Brian E Carpenter <[email-masked]>
Date: Fri, 03 Apr 2009 13:49:52 +1300

On 2009-03-30 16:17, Fred Baker wrote:
> 
> On Mar 29, 2009, at 6:40 PM, Keith Moore wrote:
> 
>> Personally, the only sense that I think the magic prefix should be a
>> "default" is in the sense of "last resort".  As in, you SHOULD use an
>> LIR prefix, and all of the relevant protocols and software need to
>> accommodate the ability to configure that LIR prefix.  But if for some
>> reason you actually think you want to use a magic prefix, please use
>> this one allocated by IANA for that purpose, rather than (say) pulling
>> one out of thin air, or using a prefix allocated for a different purpose.
> 
> If the working group would like me to word it that way, I'm OK with that.

I think that is a reasonable solution. But I'm pretty sure we need to
add an adapted version of the following rules from RFC3056:

   6to4 prefixes more specific than 2002::/16 must not be propagated in
   native IPv6 routing, to prevent pollution of the IPv6 routing table
   by elements of the IPv4 routing table.  Therefore, a 6to4 site which
   also has a native IPv6 connection MUST NOT advertise its 2002::/48
   routing prefix on that connection, and all native IPv6 network
   operators MUST filter out and discard any 2002:: routing prefix
   advertisements longer than /16.

(Yes, I wrote that text, and I am hereby contributing it under RFC5378...)

     Brian

> 
> the way the question was worded in the working group was exactly the
> opposite, and the options given were
> 
> a) only use an LIR prefix, and
> b) request a magic prefix and by default use it
> 
> There was no third option, "request a magic prefix and give guidance on
> its use"
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 03 Apr 2009 13:53:17 +1300

Xing Li,

I think we agree.

Regards
   Brian Carpenter
   University of Auckland

On 2009-03-29 03:05, Xing Li wrote:
> Brian E Carpenter 写道:
>>
>> Agreed that it would be a very bad idea. But I don't understand
>> why it would happen. It doesn't happen with 2002::/8.
>> Actually the analysis in RFC3056 states that this WKP can only be used
>> safely if the IPv4 network is not fragmented, i.e. you MUST NOT
>> use 6to4 after the IPv4 global routing breaks up (in 500 years
>> from now?). There would need to be a similar rule for a NAT64 WKP,
>> I think.
>>  
>> And the same practice would need to be used for the WKP: more specifics
>> not allowed. BTW that might recreate some of the black hole issues
>> we see for 6to4. So maybe a WKP is not such a good idea.
>>
>>     Brian
>>
>>
>>   
> I see the point now. But in the stateless mode, the effect to the global
> IPv6 Internet makes the difference.
> 
>   For the IPv6 Internet to an IPv4-network scenario, the WKP doesn't
>   work if the IPv4 is using private IPv4 addresses.  With public IPv4
>   addresses, each IPv4 site will inject a route in the IPv6 routing
>   table, i.e. importing IPv4 routing table entropy into IPv6 routing
>   table.  Therefore, the LIR should be selected.
> 
>   For "an IPv4 network to IPv4 Internet" scenario, as shown in the
>   following Figure, the stateless and stateful mode should be discussed
>   separately"
> 
>            ------                        -----           ------
>          /  The   \       -----        /  An   \       /  The   \
>         |  IPv4    |-----|Xlate|------|  IPv6   |-----|  IPv6    |
>          \Internet/       -----        \Network/       \Internet/
>            ------                        -----           ------
>                                   A                 B
> 
>                  Figure: An IPv4 network to IPv4 Internet
> 
>   1.  If Xlate is stateless, "an IPv6 network" will consist of hosts
>   using IVI6 addresses (more specifics of the IPv4 embedded IPv6
>   addresses).  The IVI6 hosts can communicate with both the global IPv4
>   Internet and the global IPv6 Internet.  The stateless Xlate supports
>   both IPv6 initiated communication and the IPv4 initiated
>   communications.
> 
>   1.1 In border A, "an IPv6 network" will advertise IVI6 addresses to
>   the Xlate and the Xlate will advertise the IPv4 embedded IPv6
>   addresses corresponding to 0.0.0.0/0 to "an IPv6 network".
> 
>   1.2 In border B, "an IPv6 network" will advertise IVI6 addresses with
>   proper aggregation to the IPv6 Internet and the IPv6 Internet will
>   advertise the global IPv6 routing table or 2000::/3 to "an IPv6
>   network".  In other words, "an IPv6 network" should advertise the
>   aggregated prefix of "an IPv6 network" and should neither advertise
>   the IPv4 embedded IPv6 addresses corresponding to 0.0.0.0/0 nor IVI6.
>   This can be achieved easily if LIR is used, but cannot be achieved if
>   WKP is used, since WKP is independent of the aggregated prefix of "an
>   IPv6 network".  In the case when WKP is used, the IVI6 must be
>   advertised to the IPv6 Internet in order to communicate with other
>   IPv6 hosts in the IPv6 Internet and this advertisement will
>   eventually result in the injecting of the global IPv4 routing table
>   into the global IPv6 routing system.
> 
>   2.  If Xlate is stateful, "an IPv6 network" will consist of ordinary
>   IPv6 addresses and Xlate maintains session-initiated states to map
>   between ordinary IPv6 addresses and the IPv4 addresses in the IPv4
>   address pool.  The stateful Xlate only supports IPv6 initiated
>   communication.
> 
>   2.1 In border A, "an IPv6 network" will advertise the aggregated
>   prefix of "an IPv6 network" to the Xlate and the Xlate will advertise
>   the IPv4 embedded IPv6 addresses corresponding to 0.0.0.0/0 to "an
>   IPv6 network".
> 
>   2.2 In border B, "an IPv6 network" will advertise the aggregated
>   prefix of "an IPv6 network" to the IPv6 Internet and the IPv6
>   Internet will advertise the global IPv6 routing table or 2000::/3 to
>   "an IPv6 network".  There is no need to advertise the IPv4 embedded
>   IPv6 addresses corresponding to 0.0.0.0/0 to the IPv6 Internet, if
>   translation service of "an IPv6 Internet" is not supported to other
>   IPv6 networks.  Therefore, the selection of WKP versus LIR is mainly
>   the operational consideration.
> 
> Please comment.
> 
> xing
> 
> 
>

---

From: Philip Matthews <[email-masked]>
Date: Fri, 3 Apr 2009 08:27:57 -0400

>> If the working group would like me to word it that way, I'm OK with  

My sense is: this is the prefix a device should use if the device does  
not have an LIR prefix. A device may obtain an LIR prefix in a number  
of ways (configuration, DHCP, ...) but if none of those ways are  
giving it a LIR prefix, then it should use the default.

Myself, I suspect that smaller deployments might just stick with the  
default, while larger deployments will use an LIR prefix.

- Philip

---

From: Keith Moore <[email-masked]>
Date: Sat, 04 Apr 2009 05:50:20 -0400

> not have an LIR prefix. A device may obtain an LIR prefix in a number of
> ways (configuration, DHCP, ...) but if none of those ways are giving it
> a LIR prefix, then it should use the default.

I think that's a bit too strong, especially if we believe that using a
single, distinguished prefix could do harm.

Keith

---

From: Xing Li <[email-masked]>
Date: Sat, 04 Apr 2009 22:26:43 +0800

Hi, Brian,

> I think we agree.

This is great! Thanks!

xing

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 13 Apr 2009 11:43:52 +0200

this makes sense to me
regards, marcelo

Xing Li escribió:
> I see the point now. But in the stateless mode, the effect to the 
> global IPv6 Internet makes the difference.
>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 13 Apr 2009 11:44:37 +0200

Brian E Carpenter escribió:
> we see for 6to4. 

could you expand on how this would be?

Regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 13 Apr 2009 11:45:51 +0200

Brian E Carpenter escribió:
>
>  But I'm pretty sure we need to

I agree with this text

Regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 13 Apr 2009 11:50:40 +0200

Keith,

> single, distinguished prefix could do harm.
how do you think the WK prefix can do harm in the restricted scenario 
that is being proposed, namely, the IPv6 network to the IPv4 internet case?

Regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 13 Apr 2009 12:10:40 +0200

Fred Baker escribió:
>
> On Mar 25, 2009, at 7:02 PM, Magnus Westerlund wrote:
>> Okay, I totally have missed the reference to statefull in the SIIT
>> update. I don't think the SIIT document covers all the parts necessary
>> for stateful translation. There are additional considerations due to the
>> port overloading. Thus the requirements that exist for NAT44 do apply to
>> this type of stateful translation.
>>
>> In my view it is not simply handling state that is necessary in the
>> stateful translator document. The suggested title seems very restricted.
>>
>> Are you suggesting that we expand the SIIT update document to contain
>> all the stateful packet translation rules?
>
>
> On Mar 25, 2009, at 7:09 PM, marcelo bagnulo braun wrote:
>> my take on this is that the nat64 draft would rely in the statefull 
>> draft in the same way natpt relied on SIIIT.
>
>
>
> Marcelo, maybe you could comment in more detail here. What do you see 
> the division as? In what way would you like to build on the 
> translation draft?
>
Sorry for the delay

So, basically, i see the SIITbis draft doing the stateless translations 
of the IP packet.
Essentially, SIITbis will define how to translate all the fields on the 
IP header except for the IP source and destination address and the ports.
The statefull draft will define how to translate address and ports for 
these packets in NAT64 devices.
In order to do that, state must be created maintained and discarded in 
some way, which is specified in the statefull draft.
So, it is both about maintaining a data base and using the information 
in it to translate the address and ports of the packets.
In particular, the base statefull draft will handle TCP UDP and ICMP 
(there are some ICMP messages that require state)

Does this makes sense?

Regards, marcelo

---

From: William Waites <[email-masked]>
Date: Mon, 13 Apr 2009 10:24:51 +0000

> But if for some reason you actually think you want to use
> a magic prefix, please use this one allocated by IANA for
> that purpose, rather than (say) pulling one out of thin air,
> or using a prefix allocated for a different purpose.

Current v6 implementations, standard configs, address selection
and such aside, it seems to me cleanest to try to encourage
the use of ::/96 since this is the "natural" embedding of the
v4 network space of 32 bit numbers in the 128 bit v6 space.

It just seems right to be able to type

    ping6 ::192.0.2.1

and have it do the right thing.

Using other prefixes seems like an ugly (though perhaps
necessary and by all means to be envisioned by the draft)
hack to me.

-w
-- 
William Waites
+49 30 8894 9942

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 13 Apr 2009 17:04:45 +0200

William Waites escribió:
> and such aside,

but this is exactly the problem with this prefix
I mean, if we use ::/96 as the WK prefix, current rfc3484 default policy 
table will prefer ::/96 than ::ffff:0:0/96

This implies that translated connectivity will be preferred over native 
IPv4 connectivity and this exactly what we don't want afaict

Hence, the argument for having a new prefix for this.

Besides, i think that unless there is  clear benefit in reusing a 
prefix, we should stay away from reusing prefixes, since it may be 
possible that exisitng implementations handle them in particular ways.

regards, marcelo

>  it seems to me cleanest to try to encourage

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 15 Apr 2009 15:02:50 +1200

> could you expand on how this would be?

At least two bad things happen with 6to4 if the WKP is incorrectly
advertised or filtered.

1. 2002::/16 is advertised too far - that is to say, A advertises it to B,
but the relay that A is operating has an ACL that drops IPv6 packets from
outside A. Users sending native IPv6 packets to a 6to4 destination via B
will be sending them into a black hole. In this case, A was wrong to
export the prefix.

2. 2002::/16 is advertised too short - that is to say, A advertises it to B,
*and* is willing to relay IPv6 packets from B, but B drops the route. Users
sending native IPv6 packets to a 6to4 destination via B will get Destination
Unreachable. In this case, B was wrong to filter the prefix.

Actually, the correct solution is that every ISP offering native IPv6 service
MUST either operate an inbound (to 6to4) relay or support a 2002::/16 route
to such a relay, and MUST NOT advertise such a route to other ISPs unless
it is willing to accept all traffic.

I'm sure similar problems would arise with a NAT64 WKP, if used carelessly.
But I think Xing Li's analysis a few days ago was correct.

   Brian

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 15 Apr 2009 09:52:06 +0200

Fred Baker escribió:
> That is sheer idiocy, and is exactly what I expect to se happen if you 
> force the galloping complexity you propose here on me. The 
> specification is already five documents (framework, translation, 
> stateful translation database, DNS ALG, and FTP ALG) and as of Tuesday 
> is slated to become six documents, splitting the prefix out of the 
> framework document into a document that you are asking me to not refer 
> to but which was internal to SIIT and was referred to in several places.
>

since the WK prefix is going to be used only in the statefull translator 
i would suggest we assign the WK prefix in the IANA cosniderations of 
the statefull draft.
So, we would keep all the discussion about the prefixes in the framework 
document as it is, we keep it informational, and we make the actual 
request for the prefix in the IANA considerations of the statefull draft.
In this way, we keep the number of documents lower, we keep the 
framework as informational with the overall prefix analysis and 
reccomendations, and we define the WK prefix in the a standard track 
document.
We should also include Brian proposed text on filtering the WK prefix in 
both documents imho

Would that make sense to you?

Regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 15 Apr 2009 10:33:50 +0200

agree
thanks, marcelo

---

From: William Waites <[email-masked]>
Date: Wed, 15 Apr 2009 10:42:01 +0100

2009/4/13 marcelo bagnulo braun <[email-masked]>:
> This implies that translated connectivity will be preferred over native IPv4
> connectivity and this exactly what we don't want afaict

True though it is not out of the question that the default policy
be revisited. In fact the policy in section 10.3 of RFC3484 is
probably more reasonable than the default and does not
suffer from this problem.

In fact section 3.2 says, " IPv4 addresses should be treated
as having "preferred" (in the RFC2462 sense) configuration
status." which is satisfied by the policy from section 10.3 but
not by the default policy as far as I can tell.

> Besides, i think that unless there is  clear benefit in reusing a prefix, we
> should stay away from reusing prefixes, since it may be possible that
> exisitng implementations handle them in particular ways.

On the other hand there's the question of how multiple
embeddings of the same numbering space - in an ideal
world we would not have ::ffff:0:0/96 either. A v6 node
wanting to talk to a v4 node would use its v4 address
embedded in v6 space. If native v4 connectivity is
available, use that, otherwise route the packets like any
other.

The semantics are clear, an application says, "I want to
talk to X host uniquely identified by that address" and
doesn't have to add routing hints into the address and
worry too much about how it wants to do so.

Put another way, if an address is not configured on a
host should not, in general appear as a destination on
the wire.

Specifically with respect to ::/96, all implementations I
am aware of either ignore it or add a reject route for it in
their startup scripts.

Just my €0.02

-w
-- 
William Waites
+49 30 8894 9942

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 15 Apr 2009 13:16:49 +0200

> available, use that, otherwise route the packets like any

This is completely doable with a bump-in-the-API type solution,  
where ::ffff:12.34.56.78 generates IPv4 packets towards 12.34.56.78 if  
there is IPv4 connectivity, but IPv6 packets to Pref64::12.34.56.78 if  
there is no native IPv4, but there is a translator available and the  
translator prefix is known.

But if this is something you want you're probably better off with dual  
stack light, which is being worked upon in the softwire wg. NAT64 is  
more useful in cases where the desire to talk to the IPv4 world is  
less prominent so making the IPv4 world appear as part of the IPv6  
world is useful.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 16 Apr 2009 11:44:42 +0200

> But I think Xing Li's analysis a few days ago was correct.

The big difference between the 6to4 prefix and a NAT64 well-known  
prefix would be that the presence of 2002::/16 in the routing tables  
throughout the internet in some way is assumed, and trouble arises  
when this prefix can't be reached. With NAT64 there is no assumption  
(yet?) that each IPv6 host can blindly assume the NAT64 exists.

Also, with 2002::/16 the prefix is advertised globally by a good  
number of people. With the NAT64 WKP this would presumably not happen,  
and advertising it between ASes at all should probably be rare.  
Basically, 2002::/16 has global scope but the NAT64 WKP would have ULA- 
like scope: some exceptions are possible, but site scope is assumed.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 17 Apr 2009 11:45:28 +1200

Iljitsch,

On 2009-04-16 21:44, Iljitsch van Beijnum wrote:
> The big difference between the 6to4 prefix and a NAT64 well-known prefix
> would be that the presence of 2002::/16 in the routing tables throughout
> the internet in some way is assumed, and trouble arises when this prefix
> can't be reached. With NAT64 there is no assumption (yet?) that each
> IPv6 host can blindly assume the NAT64 exists.
> 
> Also, with 2002::/16 the prefix is advertised globally by a good number
> of people. With the NAT64 WKP this would presumably not happen, and
> advertising it between ASes at all should probably be rare. Basically,
> 2002::/16 has global scope but the NAT64 WKP would have ULA-like scope:
> some exceptions are possible, but site scope is assumed.

I don't think we're in disagreement. The similarity with 2002::/16 is
that if you mess up the scope of the advertisement, you end up in trouble.
Unfortunately, the practical evidence from 2002::/16 is that people do
mess this up (and they mess up advertisement of 192.88.99.0/24 too).
We should have put more operational rules into RFC3056 and RFC3068,
and we need to have very clear operational rules for a NAT64 WKP.
Especially if exceptions from strict site-only scope are allowed.

    Brian

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 20 Apr 2009 18:26:44 -0700

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Brian E Carpenter
> Sent: Thursday, April 16, 2009 4:45 PM
> To: Iljitsch van Beijnum
> Cc: Xing Li; Behave WG; Fred Baker; Hiroshi MIYATA
> Subject: Re: [BEHAVE] Plan for IPv4/IPv6 translation documents
> 
> Iljitsch,
> 
> >> 1. 2002::/16 is advertised too far - that is to say, A 
> advertises it
> >> to B,
> >> 2. 2002::/16 is advertised too short - that is to say, A 
> advertises it
> >> to B,
> >> *and* is willing to relay IPv6 packets from B, but B drops 
> the route.
> >> Users
> >> Actually, the correct solution is that every ISP offering 
> native IPv6
> >> service
> >> MUST either operate an inbound (to 6to4) relay or support 
> a 2002::/16
> >> route

Are operational rules effective?

For example, let us imagine that we fast-tracked a BCP-track RFC that
encouraged Doing The Right Thing regarding advertising 2002::/16.  Twelve
months after publication -- sufficient time for the industry to internalize
that RFC -- would the RFC cause an measurable reduction in the number of
mis-advertised 2002::/16 routes?

-d

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 21 Apr 2009 13:35:12 +1200

On 2009-04-21 13:26, Dan Wing wrote:
...
> mis-advertised 2002::/16 routes?

I think a couple of paragraphs in the relevant O'Reilly book might have more
impact. Bad habits that result from oversights in RFCs are hard to break
by writing more RFCs.

So, I think we need to be sure that the IPv4/IPv6 translation documents
contain the best possible operational advice we can come up with.

    Brian

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 20 Apr 2009 18:48:38 -0700

> contain the best possible operational advice we can come up with.

My real question is:

Does the risk (of black hole routes being created) outweigh
the benefit of a Well Known prefix.

-d

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 24 Apr 2009 11:09:58 +1200

Dan,

On 2009-04-21 13:48, Dan Wing wrote:
...
> the benefit of a Well Known prefix.

Even after a lot of on- and off-list discussion, I have trouble
answering that question in the abstract.

If the exact rules for the WKP are such that only a flagrant
breach of a MUST or MUST NOT can cause a black hole, I would
agree to a WKP as an optional alternative to LIR. If we can't
make the WKP rules completely clear, we can't evaluate the risk.

   Brian

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 24 Apr 2009 11:28:53 +0200

> make the WKP rules completely clear, we can't evaluate the risk.

I thbk that if we want to be conservative and stay away from trouble, we 
can use a similar text to the one available in the ULA RFC (which is 
more restrictive than the one you sent for the 6to4)

Rephrasing it, it would look something like this:

   Addresses containing the WKP is designed to be routed inside of a site in
   the same manner as other types of unicast addresses.  They can be
   carried in any IPv6 routing protocol without any change.

   The default behavior of exterior routing protocol sessions between
   administrative routing regions must be to ignore receipt of and not
   advertise prefixes in the WKP block.  A network operator may
   specifically configure routes for the WKP for inter-site communication.

   If BGP is being used at the site border with an ISP, the default BGP
   configuration must filter out the WKP, both
   incoming and outgoing.  It must be set both to keep any WKP
   from being advertised outside of the site as well as
   to keep this prefixes from being learned from another site. 

Are these good for you?

Regards, marcelo

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 24 Apr 2009 09:25:32 -0700

> From: marcelo bagnulo braun [mailto:[email-masked]] 
> Sent: Friday, April 24, 2009 2:29 AM
> To: Brian E Carpenter
> Cc: Dan Wing; 'Behave WG'
> Subject: Re: [BEHAVE] WKP risk [Re: Plan for IPv4/IPv6 
> translation documents]
> 
                        ^
                     interior

>    to keep this prefixes from being learned from another site. 

Second and third paragraph are somewhat redundant.

RFC2119 language would improve the text.

The text does seem to capture the WG consensus on WK prefix, and
this is certainly the safest recommendation at this point in time.

-d

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 25 Apr 2009 08:46:50 +1200

I agree with Dan.

   Brian

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 24 Apr 2009 14:18:22 -0700

Just another thought on prefixes used for translation.
We already have a prefix form for intra-site tunneling:

  PREFIX:0x:00:5E:FE:V4ADDR
                  ^^

where "PREFIX" is a /64 prefix and "V4ADDR" is a 32-bit
IPv4 address. What if we were to define a corresponding
prefix form for intra-site *translation* as:

  PREFIX:0x:00:5E:FD:V4ADDR
                  ^^

This means that a single /64 could be assigned to a
tunneling-plus-translation interface, and the 'FE'
vs. 'FD' would tell the interface when to tunnel vs.
when to translate, respectively.

Comments?

Fred
[email-masked]

> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Friday, April 24, 2009 1:47 PM
> To: Dan Wing
> Cc: 'Behave WG'
> Subject: Re: [BEHAVE] WKP risk [Re: Plan for IPv4/IPv6 translation documents]
> 
> I agree with Dan.
> 
>    Brian
>

---

From: Dave Thaler <[email-masked]>
Date: Fri, 24 Apr 2009 18:24:57 -0700

The choice to tunnel or not is really made based on the choice of
the /64 prefix, not the suffix per se.  The 5efe suffix really just
indicates that there's an embedded IPv4 address (and hence can
be used by things like an address-to-string converter).

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Templin, Fred L [[email-masked]]
Sent: Friday, April 24, 2009 2:18 PM
To: Brian E Carpenter; Dan Wing
Cc: Behave WG
Subject: Re: [BEHAVE] WKP risk [Re: Plan for IPv4/IPv6 translation documents]

Comments?

Fred

---

From: Dave Thaler <[email-masked]>
Date: Fri, 24 Apr 2009 18:31:34 -0700

I agree with this approach, including Dan's feedback.

-Dave

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Dan Wing [[email-masked]]
Sent: Friday, April 24, 2009 9:25 AM
To: 'marcelo bagnulo braun'; 'Brian E Carpenter'
Cc: 'Behave WG'
Subject: Re: [BEHAVE] WKP risk [Re: Plan for IPv4/IPv6 translation documents]

                        ^
                     interior

-d