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

From: Fred Baker <[email-masked]>
Date: Wed, 25 Mar 2009 12:05:06 -0700

Referring to the October discussion and the chair's slides yesterday,  
and further to private email among the framework authors, the chairs,  
and Magnus yesterday and today, I want to capture what I understand to  
be the documentation plan. If I have it wrong, I would like to know  
that now; if I have it right I am already in process and want  
confirmation of the fact.

One thing discussed privately is that the reference from the  
translation document to the prefix is normative, which means that the  
document referred to should be standards track. You asked me to pull  
the prefix into a separate document.

So I understand that we have six documents called for at this point,  
with possible future ALG documents, for which I am suggesting  
appropriate monikers:

IPv4/IPv6 Translation Framework
     Informational, based on draft-baker-behave-v4v6-framework-02.txt
     draft-ietf-behave-v4v6-framework-00.txt
IPv4/IPv6 Translation Prefix recommendation
     Standards track, based on draft-baker-behave-v4v6-framework-02.txt
     draft-ietf-behave-v4v6-prefix-00.txt
IP/ICMP Translation
     Standards track, based on draft-baker-behave-v4v6- 
translation-02.txt
     draft-ietf-behave-v4v6-translation-00.txt
IPv4/IPv6 Stateful Translation Database Maintenance
     Standards track, based on draft-bagnulo-behave-nat64-03.txt
     draft-ietf-behave-v4v6-database-00.txt
IPv4/IPv6 DNS Translation Database Algorithm and Gateway
     Standards track, based on draft-bagnulo-behave-dns64-02.txt
     draft-ietf-behave-v4v6-dns-00.txt
IPv4/IPv6 FTP Application Layer Gateway
     Standards Track, to be determined

Am I correct?

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 25 Mar 2009 14:51:04 -0700

>     draft-ietf-behave-v4v6-database-00.txt

I think the Title of the this work is not consistent with what I would
expect the document to consist of. It is not only the binding database,
but also the actual translation that needs to be documented in this spec.

>     draft-ietf-behave-v4v6-dns-00.txt

Also in this case I wonder from where the words "Translation Database"
is comming.

-- 

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]
----------------------------------------------------------------------

---

From: Fred Baker <[email-masked]>
Date: Wed, 25 Mar 2009 15:02:39 -0700

> but also the actual translation that needs to be documented in this  

It is already documented in the translation spec. Maybe you can tell  
me what needs to be specified there that isn't. What remains t be  
specified, and what I understood to be the topic of this document, is  
the issues of stateful translation that are not in the data path.

I refer you to the text that reads

Abstract

    This document specifies an update to the Stateless IP/ICMP
    Translation Algorithm (SIIT) described in RFC 2765.  The algorithm
    translates between IPv4 and IPv6 packet headers (including ICMP
    headers).

    This specification addresses both a stateless and a stateful mode.
    In the stateless mode, translation information is carried in the
    address itself, permitting both IPv4->IPv6 and IPv6->IPv4 session
    establishment with neither state nor configuration in the IP/ICMP
    translator.  In the stateful mode, translation state is maintained
    between IPv4 address/transport port tuples and IPv6 address/ 
transport
    port tuples, enabling IPv6 systems to open sessions with IPv4
    systems.  The choice of operational mode is made by the operator
    deploying the network and is critical to the operation of the
    applications using it.

    Significant issues exist in the stateless and stateful modes that  
are
    not addressed in this document, related to the address assignment  
and
    the maintenance of the translation tables, respectively.  This
    document confines itself to the actual translation.
...

I also refer you to the discussion in section 1.3, and the two bits of  
text regarding the actual translation:

IPv4->IPv6:
    Source Address:  The source address is derived from the IPv4 source
       address to form IPv4-embedded IPv6 address as specified in
       [I-D.baker-behave-v4v6-framework].

    Destination Address:  In stateless mode, which is to say that if the
       IPv4 destination address is within the range of the stateless
       translation prefix, the destination address is derived from the
       IPv4 destination address.

       In stateful mode, which is to say that if the IPv4 destination
       address is not within the range of the stateless translation
       prefix, the IPv4-related IPv6 address and corresponding transport
       layer destination port are derived from the database reflecting
       current session state in the translator.

IPv6->IPv4:
    Source Address:  In stateless mode, which is to say that if the IPv6
       source address is within the range of the stateless translation
       prefix, the source address is derived from the IPv4-embedded IPv6
       address.

       In stateful mode, which is to say that if the IPv6 source address
       is not within the range of the stateless translation prefix, the
       IPv4 source address and transport layer source port corresponding
       to the IPv4-related IPv6 source address and source port are
       derived from the database reflecting current session state in the
       translator.

    Destination Address:  IPv6 packets that are translated have an IPv4-
       mapped destination address.  Thus the address is derived from the
       IPv6 address as specified in [I-D.baker-behave-v4v6-framework].

Those are the only differences in the data path between stateful and  
stateless mode.

> Also in this case I wonder from where the words "Translation Database"

The description of the "stateful" mode of translation implies the  
maintenance of dynamic state. That state is the correlation between  
IPv4 {address,port} tuples and IPv6 {address,port} tuples. The state  
database is where that is stored. Questions here relate to what data  
is there, how it gets into the database, how it gets removed from the  
database, and any issues that arise in the maintenance of the database.

---

From: Fred Baker <[email-masked]>
Date: Wed, 25 Mar 2009 16:01:35 -0700

Coming back to the discussion you and I had yesterday, I sat down last  
night and wrote something that resembles C code but should probably be  
thought of as pseudocode in its present state. If folks think it has  
value, I could include this in the translation draft as a non- 
normative worked-example appendix.

This big worry that I have with a separate specification for stateful  
and stateless translation in separate drafts is what my friends back  
at the ranch will do with them. At the point where some idiot looks at  
two potentially-incompatible specifications (read the translation  
draft and the NAT64 draft and ask yourself if you would automatically  
assume they are compatible) and decides that they need separate chips  
or (God help us) cards, and further decides that he'll do one in this  
release and one in the next, when what is needed is separate paths  
through and if-then-else conditional, the working group has  
fundamentally failed. And yes, I believe that this is possible; I know  
my guys back at the ranch and how they parse features.

---

From: Hiroshi MIYATA <[email-masked]>
Date: Thu, 26 Mar 2009 08:17:17 +0900

Fred,

I agree making separate prefix recommendation document, since we would  
have well known
prefix for translator.
WKP would work with some restriction, like IPv6 network to IPv4  
internet.

The document also need to describe the nature of PREFIX64(WKP and LIR)  
and limitation of usage.

Yesterday meeting, I realized at least following items to be mentioned  
explicitly otherwise the
users would face problems.

- Context exchange w/ WKP + subnet bit
   We can not know the network topology of other site.
   So, when a node was informed synthetic address w/ subnet bit it  
would face problem, if it has only one nat64 box.
   To resolve this, the administrator needs to configure to lead all  
subnet bit to the only one nat64 box.

- WKP is used only for IPv6 network to IPv4 internet
- WKP MUST be concatenated with Global IPv4 address, otherwise  
referrals does not work well.
   If the private address is concatenated, it would make some problem.
   (When Private4a = Private4b = 10.0.0.0/8, it is difficult to  
distinguish)

	(IPv4 INTERNET)
            |       |
           NAT     NAT
            |       |
        Private4a  Private4b
            |       |
           NAT64   NAT64
            |       |
         IPv6Net  IPv6Net

- WKP needs policy
	e.g., the routing information must not announced to outside.
               The ALG can inform the synthesized address with WKP or  
not.

Some of them can be resolved by engineering in well managed  
environment, but in general
it has some restriction.

Which document we should based on is another discussion. ;-)

Thanks,

....miyata

On 2009/03/26, at 4:05, Fred Baker wrote:

> Referring to the October discussion and the chair's slides  
> yesterday, and further to private email among the framework authors,  
> the chairs, and Magnus yesterday and today, I want to capture what I  
> understand to be the documentation plan. If I have it wrong, I would  
> like to know that now; if I have it right I am already in process  
> and want confirmation of the fact.
>
> translation document to the prefix is normative, which means that  
> the document referred to should be standards track. You asked me to  
> pull the prefix into a separate document.
>
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 25 Mar 2009 19:02:15 -0700

Fred,

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?

Regards

Magnus

Fred Baker skrev:
> It is already documented in the translation spec. Maybe you can tell me
> what needs to be specified there that isn't. What remains t be
>    between IPv4 address/transport port tuples and IPv6 address/transport
>    Significant issues exist in the stateless and stateful modes that are
>    not addressed in this document, related to the address assignment and
> maintenance of dynamic state. That state is the correlation between IPv4
> {address,port} tuples and IPv6 {address,port} tuples. The state database
> is where that is stored. Questions here relate to what data is there,
> how it gets into the database, how it gets removed from the database,
> and any issues that arise in the maintenance of the database.
> 
> 

-- 

Magnus Westerlund

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 26 Mar 2009 03:09:50 +0100

> but also the actual translation that needs to be documented in this spec.
my take on this is that the nat64 draft would rely in the statefull 
draft in the same way natpt relied on SIIIT.

Regards, marcelo

---

From: Fred Baker <[email-masked]>
Date: Wed, 25 Mar 2009 19:26:44 -0700

> 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?

---

From: Xing Li <[email-masked]>
Date: Thu, 26 Mar 2009 12:53:03 +0800

Fred Baker 写道:
> Standards track, based on draft-baker-behave-v4v6-translation-02.txt
Yes, this is our understanding.

xing

---

From: Xing Li <[email-masked]>
Date: Thu, 26 Mar 2009 21:39:53 +0800

Hiroshi MIYATA 写道:
> WKP would work with some restriction, like IPv6 network to IPv4 internet.

For the stateless translator, the LIR is the only choice since we should 
not insert the global IPv4 routing table into global IPv6 routing system.

> Which document we should based on is another discussion. ;-)
In the draft-baker-behave-v4v6-framework-02.txt, it summarizes both the 
stateless and the stateful modes of the translator, while the others 
only address the stateful mode.

xing

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 26 Mar 2009 15:55:31 +0100

Xing Li escribió:
> Hiroshi MIYATA 写道:
>> Fred,
>>
>> I agree making separate prefix recommendation document, since we 
>> would have well known
>> prefix for translator.
> For the stateless translator, the LIR is the only choice since we 
> should not insert the global IPv4 routing table into global IPv6 
> routing system.
>
imho this problem is not related to stateless or statefull, but related 
to whether the scenario involves an IPv6 network or the IPv6 Internet 
(i.e. by definition, you cannot inject the IPv4 routing table into the 
IPv6 internet if the scenarion does not involves the IPv6 internet)

regards, marcelo

> In the draft-baker-behave-v4v6-framework-02.txt, it summarizes both 
> the stateless and the stateful modes of the translator, while the 
> others only address the stateful mode.
>
> xing
>
>

---

From: Xing Li <[email-masked]>
Date: Fri, 27 Mar 2009 22:06:53 +0800

marcelo bagnulo braun 写道:
> imho this problem is not related to stateless or statefull, but 
> related to whether the scenario involves an IPv6 network or the IPv6 
> Internet (i.e. by definition, you cannot inject the IPv4 routing table 
> into the IPv6 internet if the scenarion does not involves the IPv6 
> internet)
>

It is strongle related to the stateless/stateful mode. Please see text 
in the framework document.

2.2.1. LIR prefix versus Well-Known prefix
2.2.1.1. Stateless mode
2.2.1.1.1. IPv6 Routing system scalability

   In the stateless mode, the more specifics inside the IPv4-embedded
   IPv6 address block are used to represent the IPv6 end systems,
   therefore the LIR prefix should be used.  The reason is that the LIR
   prefix can be aggregated in the ISP's border routers and will not
   affect the global IPv6 routing system.  On the other hand, if the
   Well-Known prefix is used, the global IPv4 routing table will be
   inserted into the global IPv6 routing system, which is known to be a
   very bad idea.

   In the stateless mode, it is possible to use LIR prefix to represent
   the IPv6 addresses in the IPv4 Internet and use Well-Known prefix to
   represent the IPv4 addresses in the IPv6 Internet.  However, this is
   also a bad idea.  The reason is that there will be two possible IPv6
   addresses to represent a single IPv4 host, i.e. if the IPv4 address
   is used by a host in the IPv4 Internet, a Well-Known prefix should be
   used; if the IPv4 address (as IVI6) is used by a host in the IPv6
   Internet, a LIR prefix should be used.  The IVI6 hosts must know
   which one to use in order to communicate with that host.  However, if
   the LIR prefix is used in both representations, this problem is
   solved by the "more specific win" routing principle.

   The potential leakage of the IPv6 more specifics introduced by using
   LIR prefix could be controlled by ISP's general routing practice,
   since this specific is the same compared with other more specifics
   inside ISP's autonomous system.

http://tools.ietf.org/html/draft-baker-behave-v4v6-framework-02

regards,

xing

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 28 Mar 2009 03:47:16 +1300

>   inserted into the global IPv6 routing system, which is known to be a

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.
>   inside ISP's autonomous system.

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

---

From: Fred Baker <[email-masked]>
Date: Fri, 27 Mar 2009 08:05:51 -0700

I think you guys are speaking at cross purposes. Let me try to  
disambiguate.

Xing Li, your point is that the IPv4-in-IPv6 more specifics in the IVI  
network you run represent individual customers, and are aggregated  
into the common prefix on the IPv4 side of the translator, and that  
the entire IPv4 space is aggregated into what amounts to a default  
route on the IPv6 side. Your comment that  IPv4 more-specifics should  
generally not be brought into the IPv6 network. Right?

Marcelo, Your point about injecting the IPv4 Internet routing into "an  
IPv6 network" vs "the IPv6 Internet" is about the connectivity of that  
IPv6 network - we're only talking about the IPv6 Internet if the  
network in question is distributing routes throughout that network.

Guys, please.

As far as peering, CERNET2 peers with networks in the US,. Europe, and  
Japan. CERNET2 is part of the emerging IPv6 Internet. There is no call  
to say otherwise.

As to the issue of injection of routes, if CERNET2 was using a magic  
prefix, it would not advertise that (or the IPv4 routes it would  
imply) to its IPv6 neighbors, and one hopes that if it erroneously did  
so its neighbors would refuse the route. So in that case it would not  
provide IPv4 connectivity to its peers. However, if it is simply  
advertising its own prefix to its peers, it in effect is offering  
transit service to its IPv4-mapped prefix (which is part of its LIR  
prefix). I would imagine that CERNET2 advertises a set of less- 
specifics that in fact don't offer transit to the IPv4 network.

---

From: Xing Li <[email-masked]>
Date: Sat, 28 Mar 2009 22:05:17 +0800

> we see for 6to4. So maybe a WKP is not such a good idea.
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: Xing Li <[email-masked]>
Date: Sat, 28 Mar 2009 22:09:35 +0800

> generally not be brought into the IPv6 network. Right?

Yes.

> prefix). I would imagine that CERNET2 advertises a set of 
> less-specifics that in fact don't offer transit to the IPv4 network.
Yes.

Thanks for the comments.

xing

---

From: Philip Matthews <[email-masked]>
Date: Sun, 29 Mar 2009 11:18:13 -0700

I would like to propose a variation on Fred's proposal.

Specifically, I would like the "IP/ICMP Translation" document (which I  
will call "SIITbis") to NOT refer to the other documents, but to stand  
on its own. The current SIIT document has proven very useful in a  
variety of contexts, and I would like to keep that generality in the  
updated version. (For example, draft-ietf-behave-turn-v6 currently  
refers to SIIT, but is somewhat unrelated to the documents below.)  
This means that SIITbis would have normative dependencies only on  
existing RFCs, and thus not get delayed by other documents.

For that reason, I would like to break out the Stateless translation  
stuff into a separate document (to be perhaps based on draft-baker- 
behave-ivi).

The following diagram may explain this better:

           +---------------+             +------------------+
           |   Stateful    |             |    Stateless     |
           |     nat64     |             |       ivi        |
           +---------------+             +------------------+
                 |      \                   /     |
                 |        --------\ /.......      |
                 v         ....../ \---------     |
           +---------------v----+        +---v----v---------+
           |    SIITbis         |        |      Prefix      |
           |                    |        |                  |
           +--------------------+        +------------------+

(Arrows are difficult to draw in ASCII art, but this shows the  
Stateful and Stateless translation documents as having normative  
dependencies on the SIITbis and Prefix documents, but no reverse  
pointers. Furthermore, draft-ietf-behave-turn-v6 may have a normative  
dependency on SIITbis, but not on the other documents).

IN PRACTICE, this means that SIITbis should do the following:
* Have no normative dependencies on any document not currently  
published as an RFC;
* Say that "this is not a complete specification, and any document  
using this specification must provide certain information  which is  
deliberately left unspecified";
* Whenever it talks about address or port or ICMP identifier field  
translation, simply state "the details of how this field is translated  
is left to the document using this specification".

Then the Stateful and Stateless translation documents will fill in the  
blanks left in SIITbis.

Comments?

- Philip

---

From: Fred Baker <[email-masked]>
Date: Sun, 29 Mar 2009 17:39:41 -0700

Speaking strictly for myself, I object.

I refer you to the code I showed you Friday morning, which I have  
posted at ftp://ftpeng.cisco.com/fred/behave/translate.c.numbered.  
This is a prototype implementation, more pseudo-code than true C, but  
could be turned into an implementation with a little thought.

What you are proposing is five documents to describe the conditional  
on lines 286-293 (a simple if-then-else with one function call and two  
procedure calls) and the similar conditional lines 317-330, with their  
supporting code on lines 201-265. What you are proposing is five  
internet drafts to describe a single very wee bit of code.

As I told you verbally, here is what has happened with SIIT and NAT-PT  
at Cisco and what I expect to happen again given this working groups  
predilection for making things more complex than they need to be. With  
SIIT and NAT-PT, which put the stateless and stateful modes in  
separate RFCs, one was implemented (NAT-PT) and one was not (SIIT)  
except in the sense that NAT-PT refers to it. The fact that they were  
in separate documents was interpreted as "this is a choice" as opposed  
to "these are different parts of one algorithm".

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.

I would REALLY like to keep this implementable. I don't see value in  
breaking two C conditional statements into five documents in search of  
a science fair project trying to understand them. I would like to see  
this as commercial product implementable from the RFCs, which means  
that the RFCs have to refer to each other, and entire algorithms have  
to be written in single documents.

I have the same view regarding the magic prefix. Operational folks,  
including but not limited to my co-authors and members of the IAB,  
have told the working group that using a magic prefix is theoretically  
possible but for practical reasons not what operators do. I have said  
as much in two working group meetings. The result as pushed by the  
computer scientists in the room is that we will implement a magic  
prefix even though the operators won't use it - and we will recommend  
that as the default. Another science fair project. I would really  
prefer to have the recommendations for operating the facility in line  
with the recommendations of the operational folks that have deployed it.

On Mar 29, 2009, at 11:18 AM, Philip Matthews wrote:

> Specifically, I would like the "IP/ICMP Translation" document (which  
> I will call "SIITbis") to NOT refer to the other documents, but to  
> stand on its own. The current SIIT document has proven very useful  
> in a variety of contexts, and I would like to keep that generality  
> in the updated version. (For example, draft-ietf-behave-turn-v6  
> currently refers to SIIT, but is somewhat unrelated to the documents  
> below.) This means that SIITbis would have normative dependencies  
> only on existing RFCs, and thus not get delayed by other documents.
>
> pointers. Furthermore, draft-ietf-behave-turn-v6 may have a  
> normative dependency on SIITbis, but not on the other documents).
>
> translation, simply state "the details of how this field is  
> translated is left to the document using this specification".
>
> Then the Stateful and Stateless translation documents will fill in  
> the blanks left in SIITbis.
>
> Comments?
>
> - Philip
>
>
>> yesterday, and further to private email among the framework  
>> authors, the chairs, and Magnus yesterday and today, I want to  
>> capture what I understand to be the documentation plan. If I have  
>> it wrong, I would like to know that now; if I have it right I am  
>> already in process and want confirmation of the fact.
>>
>> So I understand that we have six documents called for at this  
>> point, with possible future ALG documents, for which I am  
>> suggesting appropriate monikers:
>>

---

From: Fred Baker <[email-masked]>
Date: Sun, 29 Mar 2009 17:54:21 -0700

Correcting one statement, I notice that in the latest IOS release  
Cisco has implemented SIIT stand-alone, as in without NAT-PT.

On Mar 29, 2009, at 5:39 PM, Fred Baker wrote:

> This is a prototype implementation, more pseudo-code than true C,  
> but could be turned into an implementation with a little thought.
>
> on lines 286-293 (a simple if-then-else with one function call and  
> two procedure calls) and the similar conditional lines 317-330, with  
> their supporting code on lines 201-265. What you are proposing is  
> five internet drafts to describe a single very wee bit of code.
>
> As I told you verbally, here is what has happened with SIIT and NAT- 
> PT at Cisco and what I expect to happen again given this working  
> groups predilection for making things more complex than they need to  
> be. With SIIT and NAT-PT, which put the stateless and stateful modes  
> in separate RFCs, one was implemented (NAT-PT) and one was not  
> (SIIT) except in the sense that NAT-PT refers to it. The fact that  
> they were in separate documents was interpreted as "this is a  
> choice" as opposed to "these are different parts of one algorithm".
>
> 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  
> 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.
>
> breaking two C conditional statements into five documents in search  
> of a science fair project trying to understand them. I would like to  
> see this as commercial product implementable from the RFCs, which  
> means that the RFCs have to refer to each other, and entire  
> algorithms have to be written in single documents.
>
> have told the working group that using a magic prefix is  
> theoretically possible but for practical reasons not what operators  
> do. I have said as much in two working group meetings. The result as  
> pushed by the computer scientists in the room is that we will  
> implement a magic prefix even though the operators won't use it -  
> and we will recommend that as the default. Another science fair  
> project. I would really prefer to have the recommendations for  
> operating the facility in line with the recommendations of the  
> operational folks that have deployed it.
>
>> Specifically, I would like the "IP/ICMP Translation" document  
>> (which I will call "SIITbis") to NOT refer to the other documents,  
>> but to stand on its own. The current SIIT document has proven very  
>> useful in a variety of contexts, and I would like to keep that  
>> generality in the updated version. (For example, draft-ietf-behave- 
>> turn-v6 currently refers to SIIT, but is somewhat unrelated to the  
>> documents below.) This means that SIITbis would have normative  
>> dependencies only on existing RFCs, and thus not get delayed by  
>> other documents.
>>
>> For that reason, I would like to break out the Stateless  
>> translation stuff into a separate document (to be perhaps based on  
>> draft-baker-behave-ivi).
>>
>>> the document referred to should be standards track. You asked me  
>>> to pull the prefix into a separate document.
>>>

---

From: Keith Moore <[email-masked]>
Date: Sun, 29 Mar 2009 20:40:02 -0500

Fred Baker wrote:

> including but not limited to my co-authors and members of the IAB, have
> told the working group that using a magic prefix is theoretically
> possible but for practical reasons not what operators do. I have said as
> much in two working group meetings. The result as pushed by the computer
> scientists in the room is that we will implement a magic prefix even
> though the operators won't use it - and we will recommend that as the
> default. 

I really didn't like the way the question was phrased in SF, but it's
hard to phrase such questions well in a WG meeting.

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.

Keith

---

From: Fred Baker <[email-masked]>
Date: Sun, 29 Mar 2009 20:17:29 -0700

On Mar 29, 2009, at 6:40 PM, Keith Moore wrote:

> "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.

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"