Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: nsp: ipv6

An RFC is an RFC when it is an RFC (Was: Question Re: best practices)

  

 
nsp ipv6 RSS feed   Index | Next | Previous | View Threaded


jeroen at unfix

May 9, 2011, 10:13 AM

Post #1 of 24 (3183 views)
Permalink
An RFC is an RFC when it is an RFC (Was: Question Re: best practices)
On 2011-May-09 19:00, Ted Mittelstaedt wrote:
> That is a draft, not a real RFC.

Ehmmm, from the top of the document:

http://tools.ietf.org/html/rfc6146

8<=============================================
Internet Engineering Task Force (IETF)
Request for Comments: 6146
Category: Standards Track
ISSN: 2070-1721
=============================================>8

The fact that it is published as an RFC, it has a number makes it an
RFC. And this RFC is a working group document AND is even Standards
Track and marked as PROPOSED STANDARD.

The draft along with it's 12 iterations are at the top, eg:
http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate-stateful-12

Nothing 'not real' about it, RFC6146 is an RFC, if you like it or not.
When sufficient deployment is there, in (like 4 years ;) then it can
even move to become a Standard, as well, it is standards track.


As it seems you have a problem with the IETF process, I suggest you
raise that on the IETF lists where people can even better put you straight.

The IETF works with a consensus model, the only way to weigh your word
in is to participate in it. The BEHAVE WG is where you want to be at for
this one.

Greets,
Jeroen


tedm at ipinc

May 9, 2011, 10:39 AM

Post #2 of 24 (3107 views)
Permalink
Re: An RFC is an RFC when it is an RFC (Was: Question Re: best practices) [In reply to]
On 5/9/2011 10:13 AM, Jeroen Massar wrote:
> On 2011-May-09 19:00, Ted Mittelstaedt wrote:
>> That is a draft, not a real RFC.
>
> Ehmmm, from the top of the document:
>
> http://tools.ietf.org/html/rfc6146
>
> 8<=============================================
> Internet Engineering Task Force (IETF)
> Request for Comments: 6146
> Category: Standards Track
> ISSN: 2070-1721
> =============================================>8
>
> The fact that it is published as an RFC, it has a number makes it an
> RFC. And this RFC is a working group document AND is even Standards
> Track and marked as PROPOSED STANDARD.
>
> The draft along with it's 12 iterations are at the top, eg:
> http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate-stateful-12
>

12 iterations ought to tell you something.

> Nothing 'not real' about it, RFC6146 is an RFC, if you like it or not.

To the general public "RFC" is shorthand for an RFC Standard, they do
not distinguish between an RFC Draft or an RFC Standard or an RFC
Informational (which carries no weight at all) RFC Draft is nothing
more than an idea.

> When sufficient deployment is there, in (like 4 years ;) then it can
> even move to become a Standard, as well, it is standards track.
>

Maybe. What is going on is that the NAT64 supporters are
attempting to get enough people to implement a draft that they can force
the issue with IETF by arguing that there's so much of it deployed
that they have to make it a standard.

>
> As it seems you have a problem with the IETF process, I suggest you
> raise that on the IETF lists where people can even better put you straight.
>

No it seems that the NAT64 people have a problem with the RFC process
because they won't take no for an answer.

> The IETF works with a consensus model, the only way to weigh your word
> in is to participate in it. The BEHAVE WG is where you want to be at for
> this one.
>

BEHAVE is just the latest in a series of NAT-in-IPv6 WG's that have
tried and failed to interject that hack of networking into IPv6.

IETF has repeatedly said NAT is a hack they don't want in IPv6. How
often does it have to be said before the NAT supporters get the message?

And in any case nothing else I have said regarding the draft has been
invalidated by your comments. It's not a standard it's a draft, if you
won't be forthright in saying that then it just indicates you are not
interested in clarity to the consumer, and any consumer ought to be
very suspicious of a vendor or anyone else who is not willing to make
it crystal clear what they are doing. And as I also said, buying
equipment that implements a draft standard is no guarantee that the
draft standard won't change - many draft standards have been abandoned
in the past without ever making it to be a standard, and many have
undergone significant revision - and the usual vendor response to a
customer who is complaining that the gear they bought 2 years ago that
implemented a draft standard but isn't compliant with the real standard
that came out of the draft, is tough cookies, buy new gear from us.

Thus, for the hypothetical OP's question (which sounded suspiciously
like a troll anyway) to get into fooling with gear that implements a
draft standard is going to be very costly, and nobody should do it
unless they can realize an immediate financial gain for doing so, that
will pay back the investment - because for sure, your going to be buying
more gear when the draft standard is changed in the future. While a
handful of content providers might be able to answer Yes to this, the
general public will not be able to.

Ted

> Greets,
> Jeroen


martin at millnert

May 9, 2011, 10:56 AM

Post #3 of 24 (3106 views)
Permalink
Re: An RFC is an RFC when it is an RFC (Was: Question Re: best practices) [In reply to]
On Mon, 2011-05-09 at 10:39 -0700, Ted Mittelstaedt wrote:
> On 5/9/2011 10:13 AM, Jeroen Massar wrote:
> > On 2011-May-09 19:00, Ted Mittelstaedt wrote:
> >> That is a draft, not a real RFC.
> >
> > Ehmmm, from the top of the document:
> >
> > http://tools.ietf.org/html/rfc6146
> >
> > 8<=============================================
> > Internet Engineering Task Force (IETF)
> > Request for Comments: 6146
> > Category: Standards Track
> > ISSN: 2070-1721
> > =============================================>8
> >

Ted, you seem to be educating us on three issues:
1) NAT is bad,
2) that 6146 is not a standard,
3) that 6146 is a draft document

re 3: I'm thoroughly confused. To us not involved in BEHAVE or experts
on IETF process, what makes 6146 not be a proposed standard in the
standards track (it does claim so)? Ok, there's a link named
"draft-ietf-behave..." on top, but that seems to be the case for other
proposed standards in the standards track by my random testing. The
'draft' in that link text is the only match of the word 'draft' in the
entire RFC, according to my browser.

On 2: do you mean that the standardization has failed to standardize the
protocols involved/proposed?

Best Regards,
Martin


tex at off

May 9, 2011, 11:03 AM

Post #4 of 24 (3108 views)
Permalink
Re: An RFC is an RFC when it is an RFC (Was: Question Re: best practices) [In reply to]
Ted Mittelstaedt wrote:
> Thus, for the hypothetical OP's question (which sounded suspiciously
> like a troll anyway) to get into fooling with gear that implements a
> draft standard is going to be very costly, and nobody should do it
> unless they can realize an immediate financial gain for doing so, that
> will pay back the investment - because for sure, your going to be buying
> more gear when the draft standard is changed in the future. While a
> handful of content providers might be able to answer Yes to this, the
> general public will not be able to.
>
> Ted
>

I have better things to do with my time than troll. It is not trolling
to ask what people are actually doing to solve this problem. I am not
particularly interested in the political ramifications of NAT vs. ...
well vs. what, really? What is the alternate proposal?

Using NAT of any sort to solve this problem is admittedly ugly, and in
many cases problematic. But if there is a specification for it, at least
it can be implemented in a uniform manner, and I (personally) don't mind
trying out some solution which may be implemented only on development
friendly systems (e.g. Unix).

Again, specifically not trying to troll, I would like to know what the
alternative proposal is. Simply saying "start with the Internet having
v6 client support" is not a rational answer. Today's Internet clients
don't support v6.

Austin


tedm at ipinc

May 9, 2011, 11:05 AM

Post #5 of 24 (3105 views)
Permalink
Re: An RFC is an RFC when it is an RFC (Was: Question Re: best practices) [In reply to]
On 5/9/2011 10:56 AM, Martin Millnert wrote:
> On Mon, 2011-05-09 at 10:39 -0700, Ted Mittelstaedt wrote:
>> On 5/9/2011 10:13 AM, Jeroen Massar wrote:
>>> On 2011-May-09 19:00, Ted Mittelstaedt wrote:
>>>> That is a draft, not a real RFC.
>>>
>>> Ehmmm, from the top of the document:
>>>
>>> http://tools.ietf.org/html/rfc6146
>>>
>>> 8<=============================================
>>> Internet Engineering Task Force (IETF)
>>> Request for Comments: 6146
>>> Category: Standards Track
>>> ISSN: 2070-1721
>>> =============================================>8
>>>
>
> Ted, you seem to be educating us on three issues:
> 1) NAT is bad,
> 2) that 6146 is not a standard,
> 3) that 6146 is a draft document
>
> re 3: I'm thoroughly confused. To us not involved in BEHAVE or experts
> on IETF process, what makes 6146 not be a proposed standard in the
> standards track (it does claim so)?

Being a draft does not automatically guarentee it will become a
standard. Use it at your own risk.

As for is NAT bad, well I think so - but I would say the same
for any other proposed standard passed off as a real standard
regardless if it had to do with NAT or not.

Ted

Ok, there's a link named
> "draft-ietf-behave..." on top, but that seems to be the case for other
> proposed standards in the standards track by my random testing. The
> 'draft' in that link text is the only match of the word 'draft' in the
> entire RFC, according to my browser.
>
> On 2: do you mean that the standardization has failed to standardize the
> protocols involved/proposed?
>
> Best Regards,
> Martin
>


cb.list6 at gmail

May 9, 2011, 11:15 AM

Post #6 of 24 (3105 views)
Permalink
Re: An RFC is an RFC when it is an RFC (Was: Question Re: best practices) [In reply to]
On Mon, May 9, 2011 at 11:05 AM, Ted Mittelstaedt <tedm [at] ipinc> wrote:
> On 5/9/2011 10:56 AM, Martin Millnert wrote:
>>
>> On Mon, 2011-05-09 at 10:39 -0700, Ted Mittelstaedt wrote:
>>>
>>> On 5/9/2011 10:13 AM, Jeroen Massar wrote:
>>>>
>>>> On 2011-May-09 19:00, Ted Mittelstaedt wrote:
>>>>>
>>>>> That is a draft, not a real RFC.
>>>>
>>>> Ehmmm, from the top of the document:
>>>>
>>>> http://tools.ietf.org/html/rfc6146
>>>>
>>>> 8<=============================================
>>>> Internet Engineering Task Force (IETF)
>>>> Request for Comments: 6146
>>>> Category: Standards Track
>>>> ISSN: 2070-1721
>>>> =============================================>8
>>>>
>>
>> Ted,  you seem to be educating us on three issues:
>>  1) NAT is bad,
>>  2) that 6146 is not a standard,
>>  3) that 6146 is a draft document
>>
>> re 3: I'm thoroughly confused.  To us not involved in BEHAVE or experts
>> on IETF process, what makes 6146 not be a proposed standard in the
>> standards track (it does claim so)?
>
> Being a draft does not automatically guarentee it will become a standard.
>  Use it at your own risk.
>
> As for is NAT bad, well I think so - but I would say the same
> for any other proposed standard passed off as a real standard
> regardless if it had to do with NAT or not.
>
> Ted
>


Soo..... These 2 drafts have the same headers, both are proposed
standards, there is no difference in their standings from an IETF
perspective, as far as i know. I am interested in hearing fact based
pointers on how i should view one as more of a standard than the
other.

http://www.ietf.org/rfc/rfc6146.txt
http://www.ietf.org/rfc/rfc2460.txt

Cameron

>  Ok, there's a link named
>>
>> "draft-ietf-behave..." on top, but that seems to be the case for other
>> proposed standards in the standards track by my random testing. The
>> 'draft' in that link text is the only match of the word 'draft' in the
>> entire RFC, according to my browser.
>>
>> On 2: do you mean that the standardization has failed to standardize the
>> protocols involved/proposed?
>>
>> Best Regards,
>> Martin
>>
>
>


dr at cluenet

May 9, 2011, 11:32 AM

Post #7 of 24 (3105 views)
Permalink
Re: An RFC is an RFC when it is an RFC (Was: Question Re: best practices) [In reply to]
On Mon, May 09, 2011 at 10:39:54AM -0700, Ted Mittelstaedt wrote:
> To the general public "RFC" is shorthand for an RFC Standard, they do
> not distinguish between an RFC Draft or an RFC Standard

There is nothing like an "RFC Draft". Your confusing a convenience link
displayed by tools.ietf.org ontop of a published RFC text with a "draft"
designation. You will notice that basically every RFC published in the
last $NOTSOSMALLNUM years will show that link to the source draft when
looking at the RFC via tools.ietf.org/html/

Regards,
Daniel

--
CLUE-RIPE -- Jabber: dr [at] cluenet -- dr [at] IRCne -- PGP: 0xA85C8AA0


marcelo at it

May 9, 2011, 12:08 PM

Post #8 of 24 (3108 views)
Permalink
Re: An RFC is an RFC when it is an RFC (Was: Question Re: best practices) [In reply to]
A brief overview of the IETF RFCs document suite.

The first step for a document in the IETF is an individual Internet Draft.
These documents can be recognized because their name is
draft-last_name_-wg_name-...
These document are the product of one or more individual and they only
represent the consensus among the authors of the document. There is no
review of any kind. We usually call these drafts. These drafts expire
every 6 months and in order to be "alive" they need to be reposted
before that.

The second step is usually a working group internet draft. These are
recongized because their name is draft-ietf-wg_name-...
These documents reflect to some degree the WG opinion, but they are work
in progress and can be significantly changed.

Once the WG agrees that a document is ready to move forward, and the
document is reviewed by the IESG and it is open for IETF wide last call
for comments, the document is progressed to RFC.

There are several types of RFCs.

There are some RFCs that are informational, which provide information
for the community.
Other RFCs are Best Current Practices, which document operational best
practices.
Other RFCs are Experimental, which document technologies that are still
not mature enough for their deployment in the internet and more
experiment is needed to understnad their impact.

And then there are the Standard Track RFCs. The key word here is Track.
Becoming an Internet standard is a path. The first step is a Proposed
Standard RFC. The second step is a Draft Standard and the third step is
a Full Internet Standard.

Now, RFCs are immutable, so in order for a document to move from
Proposed Standard to Draft standard, a new RFC must be published, with a
new number.

So, about the comments received in the ml so far:
- RFC6146 is a Standard Track RFC which status is Proposed Standard.
- RFC2460 is a Standard Track RFC which status is Draft Standard

Other examples of Proposed Standards RFC 3261 (the SIP protocol) RFC
3315 (DHCPv6)...
I hope this clarifies a bit the situation.

Regards, marcelo








El 09/05/11 20:15, Cameron Byrne escribió:
> On Mon, May 9, 2011 at 11:05 AM, Ted Mittelstaedt<tedm [at] ipinc> wrote:
>> On 5/9/2011 10:56 AM, Martin Millnert wrote:
>>> On Mon, 2011-05-09 at 10:39 -0700, Ted Mittelstaedt wrote:
>>>> On 5/9/2011 10:13 AM, Jeroen Massar wrote:
>>>>> On 2011-May-09 19:00, Ted Mittelstaedt wrote:
>>>>>> That is a draft, not a real RFC.
>>>>> Ehmmm, from the top of the document:
>>>>>
>>>>> http://tools.ietf.org/html/rfc6146
>>>>>
>>>>> 8<=============================================
>>>>> Internet Engineering Task Force (IETF)
>>>>> Request for Comments: 6146
>>>>> Category: Standards Track
>>>>> ISSN: 2070-1721
>>>>> =============================================>8
>>>>>
>>> Ted, you seem to be educating us on three issues:
>>> 1) NAT is bad,
>>> 2) that 6146 is not a standard,
>>> 3) that 6146 is a draft document
>>>
>>> re 3: I'm thoroughly confused. To us not involved in BEHAVE or experts
>>> on IETF process, what makes 6146 not be a proposed standard in the
>>> standards track (it does claim so)?
>> Being a draft does not automatically guarentee it will become a standard.
>> Use it at your own risk.
>>
>> As for is NAT bad, well I think so - but I would say the same
>> for any other proposed standard passed off as a real standard
>> regardless if it had to do with NAT or not.
>>
>> Ted
>>
>
> Soo..... These 2 drafts have the same headers, both are proposed
> standards, there is no difference in their standings from an IETF
> perspective, as far as i know. I am interested in hearing fact based
> pointers on how i should view one as more of a standard than the
> other.
>
> http://www.ietf.org/rfc/rfc6146.txt
> http://www.ietf.org/rfc/rfc2460.txt
>
> Cameron
>
>> Ok, there's a link named
>>> "draft-ietf-behave..." on top, but that seems to be the case for other
>>> proposed standards in the standards track by my random testing. The
>>> 'draft' in that link text is the only match of the word 'draft' in the
>>> entire RFC, according to my browser.
>>>
>>> On 2: do you mean that the standardization has failed to standardize the
>>> protocols involved/proposed?
>>>
>>> Best Regards,
>>> Martin
>>>
>>


jeroen at unfix

May 9, 2011, 12:20 PM

Post #9 of 24 (3101 views)
Permalink
Re: An RFC is an RFC when it is an RFC (Was: Question Re: best practices) [In reply to]
On 2011-May-09 21:08, marcelo bagnulo braun wrote:
> A brief overview of the IETF RFCs document suite.
[..]

Thanks for the write-up, that saved me quite some typing ;)

I just got to add: everybody can participate in commenting on any of
these documents and operator input is highly requested, and if you are
sneaky you do as it helps your wishes get into the RFCs and then if you
are lucky enough vendors actually implement it (they are of course free
to say 'nah, we don't do that' which happens often enough) and thus you
get what you ask for.

As for people who want to know more about the IETF, I suggest to read
http://www.ietf.org/tao.html or kick me off-list and I can probably
point you out in the right direction.

Greets,
Jeroen


tedm at ipinc

May 9, 2011, 1:00 PM

Post #10 of 24 (3105 views)
Permalink
Re: An RFC is an RFC when it is an RFC (Was: Question Re: best practices) [In reply to]
On 5/9/2011 11:15 AM, Cameron Byrne wrote:
> On Mon, May 9, 2011 at 11:05 AM, Ted Mittelstaedt<tedm [at] ipinc> wrote:
>> On 5/9/2011 10:56 AM, Martin Millnert wrote:
>>>
>>> On Mon, 2011-05-09 at 10:39 -0700, Ted Mittelstaedt wrote:
>>>>
>>>> On 5/9/2011 10:13 AM, Jeroen Massar wrote:
>>>>>
>>>>> On 2011-May-09 19:00, Ted Mittelstaedt wrote:
>>>>>>
>>>>>> That is a draft, not a real RFC.
>>>>>
>>>>> Ehmmm, from the top of the document:
>>>>>
>>>>> http://tools.ietf.org/html/rfc6146
>>>>>
>>>>> 8<=============================================
>>>>> Internet Engineering Task Force (IETF)
>>>>> Request for Comments: 6146
>>>>> Category: Standards Track
>>>>> ISSN: 2070-1721
>>>>> =============================================>8
>>>>>
>>>
>>> Ted, you seem to be educating us on three issues:
>>> 1) NAT is bad,
>>> 2) that 6146 is not a standard,
>>> 3) that 6146 is a draft document
>>>
>>> re 3: I'm thoroughly confused. To us not involved in BEHAVE or experts
>>> on IETF process, what makes 6146 not be a proposed standard in the
>>> standards track (it does claim so)?
>>
>> Being a draft does not automatically guarentee it will become a standard.
>> Use it at your own risk.
>>
>> As for is NAT bad, well I think so - but I would say the same
>> for any other proposed standard passed off as a real standard
>> regardless if it had to do with NAT or not.
>>
>> Ted
>>
>
>
> Soo..... These 2 drafts have the same headers, both are proposed
> standards, there is no difference in their standings from an IETF
> perspective, as far as i know. I am interested in hearing fact based
> pointers on how i should view one as more of a standard than the
> other.
>
> http://www.ietf.org/rfc/rfc6146.txt

Well, first of all 6146 isn't the problem the OP was talking about.

> http://www.ietf.org/rfc/rfc2460.txt

rfc2460 is a draft standard that has been replaced by proposed standards
as shown here:

http://www.rfc-editor.org/info/rfc2460

So, no, 2460 is not the same as 6146

Now, as for proposed standards vs standards, I'll refer here:

>

From http://www.rfc-editor.org/rfc/rfc2026.txt


4.1.3 Internet Standard

A specification for which significant implementation and successful
operational experience has been obtained may be elevated to the
Internet Standard level

The simple fact of the matter is that IPv6 has NOT been significantly
implemented on the Internet. Until that happens it will NOT be possible
for it to meet the requirements of standardization.

Your argument is essentially saying that since IPv6 standardization
isn't fixed in stone, that it is OK to deploy all sorts of solutions
such as NAT over IPv6 that aren't fixed in stone either.

But this argument is disingenuous.

You may note one of the requirements to be advanced to Draft
standard:

4.1.2 Draft Standard

A specification from which at least two independent and interoperable
implementations from different code bases have been developed, and
for which sufficient successful operational experience has been
obtained, may be elevated to the "Draft Standard" level.

pray tell where are the independent implementations from different code
bases?

Can you provide URL's?

Ted


> Cameron
>
>> Ok, there's a link named
>>>
>>> "draft-ietf-behave..." on top, but that seems to be the case for other
>>> proposed standards in the standards track by my random testing. The
>>> 'draft' in that link text is the only match of the word 'draft' in the
>>> entire RFC, according to my browser.
>>>
>>> On 2: do you mean that the standardization has failed to standardize the
>>> protocols involved/proposed?
>>>
>>> Best Regards,
>>> Martin
>>>
>>
>>
>


cb.list6 at gmail

May 9, 2011, 1:06 PM

Post #11 of 24 (3110 views)
Permalink
Re: An RFC is an RFC when it is an RFC (Was: Question Re: best practices) [In reply to]
On Mon, May 9, 2011 at 1:00 PM, Ted Mittelstaedt <tedm [at] ipinc> wrote:
> On 5/9/2011 11:15 AM, Cameron Byrne wrote:
>>
>> On Mon, May 9, 2011 at 11:05 AM, Ted Mittelstaedt<tedm [at] ipinc>  wrote:
>>>
>>> On 5/9/2011 10:56 AM, Martin Millnert wrote:
>>>>
>>>> On Mon, 2011-05-09 at 10:39 -0700, Ted Mittelstaedt wrote:
>>>>>
>>>>> On 5/9/2011 10:13 AM, Jeroen Massar wrote:
>>>>>>
>>>>>> On 2011-May-09 19:00, Ted Mittelstaedt wrote:
>>>>>>>
>>>>>>> That is a draft, not a real RFC.
>>>>>>
>>>>>> Ehmmm, from the top of the document:
>>>>>>
>>>>>> http://tools.ietf.org/html/rfc6146
>>>>>>
>>>>>> 8<=============================================
>>>>>> Internet Engineering Task Force (IETF)
>>>>>> Request for Comments: 6146
>>>>>> Category: Standards Track
>>>>>> ISSN: 2070-1721
>>>>>> =============================================>8
>>>>>>
>>>>
>>>> Ted,  you seem to be educating us on three issues:
>>>>  1) NAT is bad,
>>>>  2) that 6146 is not a standard,
>>>>  3) that 6146 is a draft document
>>>>
>>>> re 3: I'm thoroughly confused.  To us not involved in BEHAVE or experts
>>>> on IETF process, what makes 6146 not be a proposed standard in the
>>>> standards track (it does claim so)?
>>>
>>> Being a draft does not automatically guarentee it will become a standard.
>>>  Use it at your own risk.
>>>
>>> As for is NAT bad, well I think so - but I would say the same
>>> for any other proposed standard passed off as a real standard
>>> regardless if it had to do with NAT or not.
>>>
>>> Ted
>>>
>>
>>
>> Soo..... These 2 drafts have the same headers, both are proposed
>> standards, there is no difference in their standings from an IETF
>> perspective, as far as i know.  I am interested in hearing fact based
>> pointers on how i should view one as more of a standard than the
>> other.
>>
>> http://www.ietf.org/rfc/rfc6146.txt
>
> Well, first of all 6146 isn't the problem the OP was talking about.
>
>> http://www.ietf.org/rfc/rfc2460.txt
>
> rfc2460 is a draft standard that has been replaced by proposed standards
> as shown here:
>
> http://www.rfc-editor.org/info/rfc2460
>
> So, no, 2460 is not the same as 6146
>
> Now, as for proposed standards vs standards, I'll refer here:
>
>>
>
> From http://www.rfc-editor.org/rfc/rfc2026.txt
>
>
> 4.1.3  Internet Standard
>
>   A specification for which significant implementation and successful
>   operational experience has been obtained may be elevated to the
>   Internet Standard level
>
> The simple fact of the matter is that IPv6 has NOT been significantly
> implemented on the Internet.  Until that happens it will NOT be possible
> for it to meet the requirements of standardization.
>
> Your argument is essentially saying that since IPv6 standardization isn't
> fixed in stone, that it is OK to deploy all sorts of solutions
> such as NAT over IPv6 that aren't fixed in stone either.
>
> But this argument is disingenuous.
>
> You may note one of the requirements to be advanced to Draft
> standard:
>
> 4.1.2  Draft Standard
>
>   A specification from which at least two independent and interoperable
>   implementations from different code bases have been developed, and
>   for which sufficient successful operational experience has been
>   obtained, may be elevated to the "Draft Standard" level.
>
> pray tell where are the independent implementations from different code
> bases?
>
> Can you provide URL's?
>

http://www.a10networks.com/products/axseries-NAT64_DNS64.php

http://www.brocade.com/solutions-technology/enterprise/application-delivery/seamless-transition-to-ipv6/index.page

http://www.cisco.com/en/US/docs/ios/ios_xe/ipaddr/configuration/guide/iad_stateless_nat64_xe.html

http://www.juniper.net/techpubs/en_US/junos10.4/information-products/topic-collections/nce/nat64-ipv6-ipv4-depletion/configuring-nat64-ipv6-ipv4-depletion.pdf

http://ecdysis.viagenie.ca/

There are others as well...

Cameron
> Ted
>
>
>> Cameron
>>
>>>  Ok, there's a link named
>>>>
>>>> "draft-ietf-behave..." on top, but that seems to be the case for other
>>>> proposed standards in the standards track by my random testing. The
>>>> 'draft' in that link text is the only match of the word 'draft' in the
>>>> entire RFC, according to my browser.
>>>>
>>>> On 2: do you mean that the standardization has failed to standardize the
>>>> protocols involved/proposed?
>>>>
>>>> Best Regards,
>>>> Martin
>>>>
>>>
>>>
>>
>
>


otroan at employees

May 9, 2011, 2:07 PM

Post #12 of 24 (3103 views)
Permalink
Re: An RFC is an RFC when it is an RFC (Was: Question Re: best practices) [In reply to]
Ted,

> rfc2460 is a draft standard that has been replaced by proposed standards
> as shown here:

incorrect.
please don't spread misinformation.
there are a number of different standards level RFCs. for the ones we are talking about here on the 'standards track'.
when something is first standardised it is a "Proposed standard" (6146), then if it has been shown to work, and there is enough interest to do the process work of moving it onwards it will be come "Draft standard" (2460), then the next step, and almost no standard ever makes it this far is full standard. there appears to be about 70 of these (http://www.rfc-editor.org/categories/rfc-standard.html).

what exactly the RFC status of a technology has to do in this debate I'm unclear on though. so apologies for butting in.

cheers,
Ole


tedm at ipinc

May 9, 2011, 2:21 PM

Post #13 of 24 (3100 views)
Permalink
Re: An RFC is an RFC when it is an RFC (Was: Question Re: best practices) [In reply to]
On 5/9/2011 1:06 PM, Cameron Byrne wrote:
> On Mon, May 9, 2011 at 1:00 PM, Ted Mittelstaedt<tedm [at] ipinc> wrote:
>> On 5/9/2011 11:15 AM, Cameron Byrne wrote:
>>>
>>> On Mon, May 9, 2011 at 11:05 AM, Ted Mittelstaedt<tedm [at] ipinc> wrote:
>>>>
>>>> On 5/9/2011 10:56 AM, Martin Millnert wrote:
>>>>>
>>>>> On Mon, 2011-05-09 at 10:39 -0700, Ted Mittelstaedt wrote:
>>>>>>
>>>>>> On 5/9/2011 10:13 AM, Jeroen Massar wrote:
>>>>>>>
>>>>>>> On 2011-May-09 19:00, Ted Mittelstaedt wrote:
>>>>>>>>
>>>>>>>> That is a draft, not a real RFC.
>>>>>>>
>>>>>>> Ehmmm, from the top of the document:
>>>>>>>
>>>>>>> http://tools.ietf.org/html/rfc6146
>>>>>>>
>>>>>>> 8<=============================================
>>>>>>> Internet Engineering Task Force (IETF)
>>>>>>> Request for Comments: 6146
>>>>>>> Category: Standards Track
>>>>>>> ISSN: 2070-1721
>>>>>>> =============================================>8
>>>>>>>
>>>>>
>>>>> Ted, you seem to be educating us on three issues:
>>>>> 1) NAT is bad,
>>>>> 2) that 6146 is not a standard,
>>>>> 3) that 6146 is a draft document
>>>>>
>>>>> re 3: I'm thoroughly confused. To us not involved in BEHAVE or experts
>>>>> on IETF process, what makes 6146 not be a proposed standard in the
>>>>> standards track (it does claim so)?
>>>>
>>>> Being a draft does not automatically guarentee it will become a standard.
>>>> Use it at your own risk.
>>>>
>>>> As for is NAT bad, well I think so - but I would say the same
>>>> for any other proposed standard passed off as a real standard
>>>> regardless if it had to do with NAT or not.
>>>>
>>>> Ted
>>>>
>>>
>>>
>>> Soo..... These 2 drafts have the same headers, both are proposed
>>> standards, there is no difference in their standings from an IETF
>>> perspective, as far as i know. I am interested in hearing fact based
>>> pointers on how i should view one as more of a standard than the
>>> other.
>>>
>>> http://www.ietf.org/rfc/rfc6146.txt
>>
>> Well, first of all 6146 isn't the problem the OP was talking about.
>>
>>> http://www.ietf.org/rfc/rfc2460.txt
>>
>> rfc2460 is a draft standard that has been replaced by proposed standards
>> as shown here:
>>
>> http://www.rfc-editor.org/info/rfc2460
>>
>> So, no, 2460 is not the same as 6146
>>
>> Now, as for proposed standards vs standards, I'll refer here:
>>
>>>
>>
>> From http://www.rfc-editor.org/rfc/rfc2026.txt
>>
>>
>> 4.1.3 Internet Standard
>>
>> A specification for which significant implementation and successful
>> operational experience has been obtained may be elevated to the
>> Internet Standard level
>>
>> The simple fact of the matter is that IPv6 has NOT been significantly
>> implemented on the Internet. Until that happens it will NOT be possible
>> for it to meet the requirements of standardization.
>>
>> Your argument is essentially saying that since IPv6 standardization isn't
>> fixed in stone, that it is OK to deploy all sorts of solutions
>> such as NAT over IPv6 that aren't fixed in stone either.
>>
>> But this argument is disingenuous.
>>
>> You may note one of the requirements to be advanced to Draft
>> standard:
>>
>> 4.1.2 Draft Standard
>>
>> A specification from which at least two independent and interoperable
>> implementations from different code bases have been developed, and
>> for which sufficient successful operational experience has been
>> obtained, may be elevated to the "Draft Standard" level.
>>
>> pray tell where are the independent implementations from different code
>> bases?
>>
>> Can you provide URL's?
>>
>
> http://www.a10networks.com/products/axseries-NAT64_DNS64.php
>
> http://www.brocade.com/solutions-technology/enterprise/application-delivery/seamless-transition-to-ipv6/index.page
>
> http://www.cisco.com/en/US/docs/ios/ios_xe/ipaddr/configuration/guide/iad_stateless_nat64_xe.html
>
> http://www.juniper.net/techpubs/en_US/junos10.4/information-products/topic-collections/nce/nat64-ipv6-ipv4-depletion/configuring-nat64-ipv6-ipv4-depletion.pdf
>
> http://ecdysis.viagenie.ca/
>

Because those are proprietary we really have no way, short of signing an
NDA, of knowing if they really are independent.

For all anyone knows, every one of those commercial customers could
have signed an agreement with the guy running the ecdysis website. I
have wondered about that since the code on his site does not run on
FreeBSD, and normally an OpenBSD to FreeBSD port is child's play -
to me that indicates a lot of deep mucking around in the kernel. It's
not a very portable implementation unless he wrote it to be portable
and clearly he didn't. And last I checked it was an old version of
Linux, too.

For example just about all the small routers (Linksys, Netgear) use the
same code base. (Linux kernel)

> There are others as well...
>

Post them. I would like to see multiple open source implementations
that are buildible on current OSes. I think that is far more in the
spirit of openness that the RFC system is built on.

I have nothing against commercial companies but we have had several
very ugly incidents in the past of companies patenting
aspects of stuff they got inserted in the RFC process, and got
standardized. That is why multiple open source implementations are
critical for anything like this. Many such exist for IPv6 stacks,
incidentally.

Ted



> Cameron
>> Ted
>>
>>
>>> Cameron
>>>
>>>> Ok, there's a link named
>>>>>
>>>>> "draft-ietf-behave..." on top, but that seems to be the case for other
>>>>> proposed standards in the standards track by my random testing. The
>>>>> 'draft' in that link text is the only match of the word 'draft' in the
>>>>> entire RFC, according to my browser.
>>>>>
>>>>> On 2: do you mean that the standardization has failed to standardize the
>>>>> protocols involved/proposed?
>>>>>
>>>>> Best Regards,
>>>>> Martin
>>>>>
>>>>
>>>>
>>>
>>
>>
>


cb.list6 at gmail

May 9, 2011, 2:25 PM

Post #14 of 24 (3104 views)
Permalink
Re: An RFC is an RFC when it is an RFC (Was: Question Re: best practices) [In reply to]
On Mon, May 9, 2011 at 2:21 PM, Ted Mittelstaedt <tedm [at] ipinc> wrote:
> On 5/9/2011 1:06 PM, Cameron Byrne wrote:
>>
>> On Mon, May 9, 2011 at 1:00 PM, Ted Mittelstaedt<tedm [at] ipinc>  wrote:
>>>
>>> On 5/9/2011 11:15 AM, Cameron Byrne wrote:
>>>>
>>>> On Mon, May 9, 2011 at 11:05 AM, Ted Mittelstaedt<tedm [at] ipinc>
>>>>  wrote:
>>>>>
>>>>> On 5/9/2011 10:56 AM, Martin Millnert wrote:
>>>>>>
>>>>>> On Mon, 2011-05-09 at 10:39 -0700, Ted Mittelstaedt wrote:
>>>>>>>
>>>>>>> On 5/9/2011 10:13 AM, Jeroen Massar wrote:
>>>>>>>>
>>>>>>>> On 2011-May-09 19:00, Ted Mittelstaedt wrote:
>>>>>>>>>
>>>>>>>>> That is a draft, not a real RFC.
>>>>>>>>
>>>>>>>> Ehmmm, from the top of the document:
>>>>>>>>
>>>>>>>> http://tools.ietf.org/html/rfc6146
>>>>>>>>
>>>>>>>> 8<=============================================
>>>>>>>> Internet Engineering Task Force (IETF)
>>>>>>>> Request for Comments: 6146
>>>>>>>> Category: Standards Track
>>>>>>>> ISSN: 2070-1721
>>>>>>>> =============================================>8
>>>>>>>>
>>>>>>
>>>>>> Ted,  you seem to be educating us on three issues:
>>>>>>  1) NAT is bad,
>>>>>>  2) that 6146 is not a standard,
>>>>>>  3) that 6146 is a draft document
>>>>>>
>>>>>> re 3: I'm thoroughly confused.  To us not involved in BEHAVE or
>>>>>> experts
>>>>>> on IETF process, what makes 6146 not be a proposed standard in the
>>>>>> standards track (it does claim so)?
>>>>>
>>>>> Being a draft does not automatically guarentee it will become a
>>>>> standard.
>>>>>  Use it at your own risk.
>>>>>
>>>>> As for is NAT bad, well I think so - but I would say the same
>>>>> for any other proposed standard passed off as a real standard
>>>>> regardless if it had to do with NAT or not.
>>>>>
>>>>> Ted
>>>>>
>>>>
>>>>
>>>> Soo..... These 2 drafts have the same headers, both are proposed
>>>> standards, there is no difference in their standings from an IETF
>>>> perspective, as far as i know.  I am interested in hearing fact based
>>>> pointers on how i should view one as more of a standard than the
>>>> other.
>>>>
>>>> http://www.ietf.org/rfc/rfc6146.txt
>>>
>>> Well, first of all 6146 isn't the problem the OP was talking about.
>>>
>>>> http://www.ietf.org/rfc/rfc2460.txt
>>>
>>> rfc2460 is a draft standard that has been replaced by proposed standards
>>> as shown here:
>>>
>>> http://www.rfc-editor.org/info/rfc2460
>>>
>>> So, no, 2460 is not the same as 6146
>>>
>>> Now, as for proposed standards vs standards, I'll refer here:
>>>
>>>>
>>>
>>>  From http://www.rfc-editor.org/rfc/rfc2026.txt
>>>
>>>
>>> 4.1.3  Internet Standard
>>>
>>>   A specification for which significant implementation and successful
>>>   operational experience has been obtained may be elevated to the
>>>   Internet Standard level
>>>
>>> The simple fact of the matter is that IPv6 has NOT been significantly
>>> implemented on the Internet.  Until that happens it will NOT be possible
>>> for it to meet the requirements of standardization.
>>>
>>> Your argument is essentially saying that since IPv6 standardization isn't
>>> fixed in stone, that it is OK to deploy all sorts of solutions
>>> such as NAT over IPv6 that aren't fixed in stone either.
>>>
>>> But this argument is disingenuous.
>>>
>>> You may note one of the requirements to be advanced to Draft
>>> standard:
>>>
>>> 4.1.2  Draft Standard
>>>
>>>   A specification from which at least two independent and interoperable
>>>   implementations from different code bases have been developed, and
>>>   for which sufficient successful operational experience has been
>>>   obtained, may be elevated to the "Draft Standard" level.
>>>
>>> pray tell where are the independent implementations from different code
>>> bases?
>>>
>>> Can you provide URL's?
>>>
>>
>> http://www.a10networks.com/products/axseries-NAT64_DNS64.php
>>
>>
>> http://www.brocade.com/solutions-technology/enterprise/application-delivery/seamless-transition-to-ipv6/index.page
>>
>>
>> http://www.cisco.com/en/US/docs/ios/ios_xe/ipaddr/configuration/guide/iad_stateless_nat64_xe.html
>>
>>
>> http://www.juniper.net/techpubs/en_US/junos10.4/information-products/topic-collections/nce/nat64-ipv6-ipv4-depletion/configuring-nat64-ipv6-ipv4-depletion.pdf
>>
>> http://ecdysis.viagenie.ca/
>>
>
> Because those are proprietary we really have no way, short of signing an
> NDA, of knowing if they really are independent.
>

<plonk>

> For all anyone knows, every one of those commercial customers could
> have signed an agreement with the guy running the ecdysis website.  I
> have wondered about that since the code on his site does not run on
> FreeBSD, and normally an OpenBSD to FreeBSD port is child's play -
> to me that indicates a lot of deep mucking around in the kernel.  It's
> not a very portable implementation unless he wrote it to be portable
> and clearly he didn't.  And last I checked it was an old version of
> Linux, too.
>
> For example just about all the small routers (Linksys, Netgear) use the
> same code base. (Linux kernel)
>
>> There are others as well...
>>
>
> Post them.  I would like to see multiple open source implementations
> that are buildible on current OSes.  I think that is far more in the
> spirit of openness that the RFC system is built on.
>
> I have nothing against commercial companies but we have had several
> very ugly incidents in the past of companies patenting
> aspects of stuff they got inserted in the RFC process, and got
> standardized.  That is why multiple open source implementations are
> critical for anything like this.  Many such exist for IPv6 stacks,
> incidentally.
>
> Ted
>
>
>
>> Cameron
>>>
>>> Ted
>>>
>>>
>>>> Cameron
>>>>
>>>>>  Ok, there's a link named
>>>>>>
>>>>>> "draft-ietf-behave..." on top, but that seems to be the case for other
>>>>>> proposed standards in the standards track by my random testing. The
>>>>>> 'draft' in that link text is the only match of the word 'draft' in the
>>>>>> entire RFC, according to my browser.
>>>>>>
>>>>>> On 2: do you mean that the standardization has failed to standardize
>>>>>> the
>>>>>> protocols involved/proposed?
>>>>>>
>>>>>> Best Regards,
>>>>>> Martin
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>


sm at resistor

May 9, 2011, 2:42 PM

Post #15 of 24 (3105 views)
Permalink
Re: An RFC is an RFC when it is an RFC (Was: Question Re: best practices) [In reply to]
Hi,

What a RFC is doesn't really matter. It's better to read the
specification and see whether it is a good idea or not.

At 13:00 09-05-2011, Ted Mittelstaedt wrote:
>rfc2460 is a draft standard that has been replaced by proposed standards
>as shown here:
>
>http://www.rfc-editor.org/info/rfc2460

That RFC is updated by RFC 5095, RFC 5722 and RFC 5871.

>The simple fact of the matter is that IPv6 has NOT been significantly
>implemented on the Internet. Until that happens it will NOT be possible
>for it to meet the requirements of standardization.

I gather that instead of "implemented", the above meant
"deployed". The RFC probably meets the requirements for "Full Standard".

Regards,
-sm

P.S. Proposed Standard is the entry level on the Standards Track.


sesse at google

May 9, 2011, 2:46 PM

Post #16 of 24 (3099 views)
Permalink
Re: An RFC is an RFC when it is an RFC (Was: Question Re: best practices) [In reply to]
Den 9. mai 2011 23:21 skrev Ted Mittelstaedt <tedm [at] ipinc> følgende:
>> There are others as well...
> Post them.  I would like to see multiple open source implementations
> that are buildible on current OSes.  I think that is far more in the
> spirit of openness that the RFC system is built on.

TAYGA — http://www.litech.org/tayga/ . It doesn't do the overload part
of NAT44 (ie., one IPv6 address becomes one IPv4 address), but you can
easily do that on top with regular iptables. (I feed it into a Cisco
router which NATs for me, mostly for the fun of it.)

/* Steinar */
--
Software Engineer, Google Switzerland


tedm at ipinc

May 9, 2011, 2:48 PM

Post #17 of 24 (3105 views)
Permalink
Re: An RFC is an RFC when it is an RFC (Was: Question Re: best practices) [In reply to]
On 5/9/2011 2:07 PM, Ole Troan wrote:
> Ted,
>
>> rfc2460 is a draft standard that has been replaced by proposed
>> standards as shown here:
>
> incorrect.


http://www.rfc-editor.org/info/rfc2460

Status:
DRAFT STANDARD
Obsoletes:
RFC 1883
Updated by:
RFC 5095, RFC 5722, RFC 5871

You are correct that "replaced by" is not exactly accurate. More
accurate would be "part of it replaced by" proposed standards.

We may see more and more parts of this replaced by proposed
standards. The IETF may not ever wish to standardize IPv6 in
one single chunk, they may feel it more politically expedient to
standardize a bunch of chunks of it.

But since so many different implementations of IPv6 now exist and
are out in the wild, that follow RFC2460, compared to so few of
NAT64, (save proprietary commercial ones, which all may be the same
code) it is still rather absurd to equate the two.

> please don't spread misinformation. there are a number of different
> standards level RFCs. for the ones we are talking about here on the
> 'standards track'. when something is first standardised it is a
> "Proposed standard" (6146), then if it has been shown to work, and
> there is enough interest to do the process work of moving it onwards
> it will be come "Draft standard" (2460), then the next step, and
> almost no standard ever makes it this far is full standard. there
> appears to be about 70 of these
> (http://www.rfc-editor.org/categories/rfc-standard.html).
>

OK your making the argument now that a RFC standard is the same
thing as a Draft RFC Standard, based on the fact that the IETF
has not approved many standards.

But to accept that argument basically means your saying the IETF RFC
standards process is broken - that it's incapable of producing
standards that anyone will adhere to, so they settle for "Draft
Standard" as a politically expedient result as it allows vendors
to worm their way out of supporting older code that might not be
compliant.

But if that is the case then why drag the RFC's in to the discussion
in the first place?

> what exactly the RFC status of a technology has to do in this debate
> I'm unclear on though.

The first responders to the OP's question apparently could
not resist dragging in RFC numbers rather than (as Cameron eventually
did, after my prodding) simply produce a list of NAT64 vendor
implementations that the OP could use. Thus, the status of the RFC
became relevant.

I would say that the OP got his answer plus a list of places to go
spend his money, so I would mark this thread off as successful.

Ted

> so apologies for butting in.
>
> cheers, Ole
>
>
>
>


tedm at ipinc

May 9, 2011, 2:55 PM

Post #18 of 24 (3101 views)
Permalink
Re: An RFC is an RFC when it is an RFC (Was: Question Re: best practices) [In reply to]
On 5/9/2011 2:46 PM, Steinar H. Gunderson wrote:
> Den 9. mai 2011 23:21 skrev Ted Mittelstaedt<tedm [at] ipinc> følgende:
>>> There are others as well...
>> Post them. I would like to see multiple open source implementations
>> that are buildible on current OSes. I think that is far more in the
>> spirit of openness that the RFC system is built on.
>
> TAYGA — http://www.litech.org/tayga/ . It doesn't do the overload part
> of NAT44 (ie., one IPv6 address becomes one IPv4 address), but you can
> easily do that on top with regular iptables. (I feed it into a Cisco
> router which NATs for me, mostly for the fun of it.)
>
> /* Steinar */

Well, that's a start, but neither it nor the one at
http://ecdysis.viagenie.ca/ advertise RFC 6146 compliance, I
wonder if either of them are?

Ted


tjc at ecs

May 9, 2011, 3:12 PM

Post #19 of 24 (3094 views)
Permalink
Re: An RFC is an RFC when it is an RFC (Was: Question Re: best practices) [In reply to]
On 9 May 2011, at 22:48, Ted Mittelstaedt wrote:
>
> The first responders to the OP's question apparently could
> not resist dragging in RFC numbers rather than (as Cameron eventually
> did, after my prodding) simply produce a list of NAT64 vendor implementations that the OP could use. Thus, the status of the RFC
> became relevant.


Citing RFCs - not 'dragging them in' - is simply a way of giving the most up-to-date reference for the original poster.

Yes, some of us misread the question, but I think the answers have now been given.

Tim


simon.perreault at viagenie

May 9, 2011, 3:53 PM

Post #20 of 24 (3094 views)
Permalink
Re: An RFC is an RFC when it is an RFC (Was: Question Re: best practices) [In reply to]
On 2011-05-09 17:21, Ted Mittelstaedt wrote:
>> http://ecdysis.viagenie.ca/
>
> Because those are proprietary we really have no way, short of signing an
> NDA, of knowing if they really are independent.

Ecdysis is not proprietary, it is open source. We have two independent
NAT64 implementations: one for Linux and one for BSD. And we have two
independent DNS64 implementations: one for Bind and one for Unbound.

Simon
--
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server --> http://numb.viagenie.ca
vCard 4.0 --> http://www.vcarddav.org


simon.perreault at viagenie

May 9, 2011, 3:54 PM

Post #21 of 24 (3103 views)
Permalink
Re: An RFC is an RFC when it is an RFC (Was: Question Re: best practices) [In reply to]
On 2011-05-09 17:55, Ted Mittelstaedt wrote:
> Well, that's a start, but neither it nor the one at
> http://ecdysis.viagenie.ca/ advertise RFC 6146 compliance, I
> wonder if either of them are?

As far as I know, we're compliant. The website needs to be updated.

Simon
--
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server --> http://numb.viagenie.ca
vCard 4.0 --> http://www.vcarddav.org


tedm at ipinc

May 9, 2011, 4:51 PM

Post #22 of 24 (3098 views)
Permalink
Re: An RFC is an RFC when it is an RFC (Was: Question Re: best practices) [In reply to]
On 5/9/2011 3:53 PM, Simon Perreault wrote:
> On 2011-05-09 17:21, Ted Mittelstaedt wrote:
>>> http://ecdysis.viagenie.ca/
>>
>> Because those are proprietary we really have no way, short of signing an
>> NDA, of knowing if they really are independent.
>
> Ecdysis is not proprietary, it is open source. We have two independent
> NAT64 implementations: one for Linux and one for BSD. And we have two
> independent DNS64 implementations: one for Bind and one for Unbound.
>


And you know that those companies are NOT using your patches in their
products? The BSD licensed ones?

When are you going to update your website with the current RFCs?

OpenBSD is at 4.9 as well. Do the patches still apply to the 4.9
kernel?

Ted

> Simon


simon.perreault at viagenie

May 9, 2011, 5:15 PM

Post #23 of 24 (3097 views)
Permalink
Re: An RFC is an RFC when it is an RFC (Was: Question Re: best practices) [In reply to]
On 2011-05-09 19:51, Ted Mittelstaedt wrote:
> And you know that those companies are NOT using your patches in their
> products? The BSD licensed ones?

How is that relevant to this discussion? I spoke for our
implementations, not theirs.

> When are you going to update your website with the current RFCs?

As soon as we do it, it will be done. ;)

> OpenBSD is at 4.9 as well. Do the patches still apply to the 4.9
> kernel?

No. But there's an ongoing effort by core OpenBSD hackers to update our
code. There's a patch against CVS HEAD floating around...

Simon
--
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server --> http://numb.viagenie.ca
vCard 4.0 --> http://www.vcarddav.org


evyncke at cisco

May 9, 2011, 11:23 PM

Post #24 of 24 (3082 views)
Permalink
RE: An RFC is an RFC when it is an RFC (Was: Question Re: bestpractices) [In reply to]
A student of the University of Liège, Pierre Rondou (in cc), also did a RFC 6219 implementation and is finalizing the stateful version of it for netfilter in Linux:

http://sourceforge.net/projects/nativi/

-Ă©ric

> -----Original Message-----
> From: ipv6-ops-bounces+evyncke=cisco.com [at] lists [mailto:ipv6-ops-
> bounces+evyncke=cisco.com [at] lists] On Behalf Of Steinar H. Gunderson
> Sent: lundi 9 mai 2011 23:47
> To: Ted Mittelstaedt
> Cc: ipv6-ops [at] lists
> Subject: Re: An RFC is an RFC when it is an RFC (Was: Question Re:
> bestpractices)
>
> Den 9. mai 2011 23:21 skrev Ted Mittelstaedt <tedm [at] ipinc> følgende:
> >> There are others as well...
> > Post them.  I would like to see multiple open source implementations
> > that are buildible on current OSes.  I think that is far more in the
> > spirit of openness that the RFC system is built on.
>
> TAYGA — http://www.litech.org/tayga/ . It doesn't do the overload part
> of NAT44 (ie., one IPv6 address becomes one IPv4 address), but you can
> easily do that on top with regular iptables. (I feed it into a Cisco
> router which NATs for me, mostly for the fun of it.)
>
> /* Steinar */
> --
> Software Engineer, Google Switzerland

nsp ipv6 RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.