I had thought about the blocks of RFC6598, but because it is a well-known RFC I can have problems of the users thinking that they are behind a NAT.
>From what I have seen to this moment in this discussion is that it may be interesting to continue with the blocks of RFC1918 or use the blocks of RFC6598.
Thank you all
Em 27/10/2017 20:09, "ietf-bounces@xxxxxxxx em nome de ietf-request@xxxxxxxx" <ietf-bounces@xxxxxxxx em nome de ietf-request@xxxxxxxx> escreveu:
Send ietf mailing list submissions to
ietf@xxxxxxxx
To subscribe or unsubscribe via the World Wide Web, visit
https://www.ietf.org/mailman/listinfo/ietf
or, via email, send a message with subject or body 'help' to
ietf-request@xxxxxxxx
You can reach the person managing the list at
ietf-owner@xxxxxxxx
When replying, please edit your Subject line so it is more specific
than "Re: Contents of ietf digest..."
Today's Topics:
1. Re: IP's for point-to-point and loopbacks (Brian E Carpenter)
2. Re: IP's for point-to-point and loopbacks (Paul Wouters)
3. Re: Proposal to revise ISOC's mission statement
(Charles Eckel (eckelcu))
4. Re: Proposal to revise ISOC's mission statement
(Spencer Dawkins at IETF)
----------------------------------------------------------------------
Message: 1
Date: Sat, 28 Oct 2017 08:35:16 +1300
From: Brian E Carpenter <brian.e.carpenter@xxxxxxxxx>
To: ietf@xxxxxxxx
Subject: Re: IP's for point-to-point and loopbacks
Message-ID: <3a41b5f8-b711-cc27-d9ca-f75e7ba48da0@xxxxxxxxx>
Content-Type: text/plain; charset=utf-8
> At first I thought of using the blocks of RFC1918, but this IPs are well known and can cause a false impression on the end user.
Not just a false impression; if they show up in traceroutes they can be extremely misleading.
Has anyone considered (mis)using 100.64.0.0/10 (RFC6598) for this sort of purpose?
...
>> Finally we are thinking of using the blocks that I will present below, as they are little known and not routed worldwide.
>>
>> 198.18.0.0/15
>> 192.0.0.0/24
>> 192.0.2.0/24
>> 192.88.99.0/24
>> 198.51.100.0/24
>> 203.0.113.0/24
>>
>> What do you think about this?
A very bad idea. They are all reserved for a reason, and some
of them are well known.
192.88.99.0/24 would a particularly dangerous choice (see RFC7526).
The RIRs make it clear that none of these should be used, e.g. APNIC:
Internet Assigned Numbers Authority SPECIAL-IPV4-REGISTRY-IANA-RESERVED (NET-192-0-0-0-1) 192.0.0.0 - 192.0.0.255
Internet Assigned Numbers Authority DS-LITE-RFC-6333-11-IANA-RESERVED (NET-192-0-0-0-2) 192.0.0.0 - 192.0.0.7
NetName: 6TO4-RELAY-ANYCAST-IANA-RESERVED
NetHandle: NET-192-88-99-0-1
Parent: NET192 (NET-192-0-0-0-0)
NetType: IANA Special Use
Comment: Addresses starting with "198.18." or "198.19." are set aside for use in isolated laboratory networks used for benchmarking and performance testing. They should never appear on the Internet and if you see Internet traffic using these addresses, they are being used without permission.
Comment: Addresses starting with "192.0.2.", "198.51.100.", or "203.0.113." are reserved for use in documentation and sample configurations. They should never be used in a live network configuration. No one has permission to use these addresses on the Internet.
------------------------------
Message: 2
Date: Fri, 27 Oct 2017 23:54:41 +0400
From: Paul Wouters <paul@xxxxxxxxx>
To: Brian E Carpenter <brian.e.carpenter@xxxxxxxxx>
Cc: ietf@xxxxxxxx
Subject: Re: IP's for point-to-point and loopbacks
Message-ID: <B7EE2A70-3433-4030-A01A-EC871C78E68E@xxxxxxxxx>
Content-Type: text/plain; charset=utf-8
On Oct 27, 2017, at 23:35, Brian E Carpenter <brian.e.carpenter@xxxxxxxxx> wrote:
>> At first I thought of using the blocks of RFC1918, but this IPs are well known and can cause a false impression on the end user.
What is the false impression? They are NATed I take it?
> Not just a false impression; if they show up in traceroutes they can be extremely misleading.
I think users of traceroute are advanced enough to know rfc1918?
> Has anyone considered (mis)using 100.64.0.0/10 (RFC6598) for this sort of purpose?
Yes, I use it myself to hand out IP?s for IPsec VPN, as it has less chance of clashing with the user?s local preNAT IP range. Until others start abusing this range too.
>>> Finally we are thinking of using the blocks that I will present below, as they are little known and not routed worldwide.
>>>
>>> 198.18.0.0/15
>>> 192.0.0.0/24
>>> 192.0.2.0/24
We use the example ranges for our unit testing so I have those permanently configured on our test machines and laptop ?
> A very bad idea. They are all reserved for a reason, and some
> of them are well known.
Even the ones that are a safe choice become unsafe once people start using these.
However, there is a lot of unused multicast and reserved space left to do assignments from. I?m not sure why we haven?t started nibbling on those yet, other then wanting to promote ipv6?
Paul
------------------------------
Message: 3
Date: Fri, 27 Oct 2017 20:40:17 +0000
From: "Charles Eckel (eckelcu)" <eckelcu@xxxxxxxxx>
To: Marc Petit-Huguenin <petithug@xxxxxxx>, Alia Atlas
<akatlas@xxxxxxxxx>
Cc: Doug Royer <douglasroyer@xxxxxxxxx>, Michael Richardson
<mcr+ietf@xxxxxxxxxxxx>, Gonzalo Camarillo
<Gonzalo.Camarillo@xxxxxxxxxxxx>, IETF Discussion Mailing List
<ietf@xxxxxxxx>
Subject: Re: Proposal to revise ISOC's mission statement
Message-ID: <CBF4104B-2DEF-4F88-AD9F-59996CB58735@xxxxxxxxx>
Content-Type: text/plain; charset="utf-8"
Overall I think the new mission statement is quite good. One specific comment inline.
-----Original Message-----
From: ietf <ietf-bounces@xxxxxxxx> on behalf of Marc Petit-Huguenin <petithug@xxxxxxx>
Date: Friday, October 27, 2017 at 10:00 AM
To: Alia Atlas <akatlas@xxxxxxxxx>
Cc: Doug Royer <douglasroyer@xxxxxxxxx>, Michael Richardson <mcr+ietf@xxxxxxxxxxxx>, Gonzalo Camarillo <Gonzalo.Camarillo@xxxxxxxxxxxx>, "ietf@xxxxxxxx" <ietf@xxxxxxxx>
Subject: Re: Proposal to revise ISOC's mission statement
On 10/27/2017 09:46 AM, Alia Atlas wrote:
> On Fri, Oct 27, 2017 at 12:41 PM, Marc Petit-Huguenin <petithug@xxxxxxx
> <mailto:petithug@xxxxxxx>> wrote:
>
> On 10/27/2017 08:40 AM, Michael Richardson wrote:
> >
> > Gonzalo Camarillo <Gonzalo.Camarillo@xxxxxxxxxxxx <mailto:Gonzalo.Camarillo@xxxxxxxxxxxx>> wrote:
> > > As you know, ISOC supports the IETF in several ways (in addition to
> > > providing funding). Please, think about how ISOC could help support the
> > > IETF in potentially new ways or how the current programs could make an
> > > even larger impact, and let's have a conversation in Singapore. Thanks!
> >
> > My take is (in this order);
> > * longer, more involved Hackathons,
> > * open source reference implementations (%)
> > * cheaply and easily reproduceable test bed/skaffolding for complex protocols
> > * facilitating conformance testing, particularly for open source implementations.
>
> If we are going in that direction then I think it about time that the IETF
> starts using formal methods to verify protocols, so instead of partially
> checking that a protocol works (which is the best that hackathons or testing
> can bring to the table), we have a guarantee that they do work.
> (self-serving too, as I am working since a couple years on yet another
> markdown language that does exactly that).
>
>
> The wonderful and frustrating thing is that there isn't a single activity that
> will capture all of what would be useful.
Sure, but it would be a good start to have something in the ISOC mission statement about promoting protocol checking (hackathon, testing) and formal verifications of the IETF standards.
Rather than add more specific examples to the existing set of highlighted activities, how about adding something in the mission statement about implementation and application in addition to the development of open standards. This would leave it to the IETF community to decide on methods to achieve this, e.g. more emphasis on running code, reference implementations, protocol validation, workshops on enabling new standards and functionality, etc.
Cheers,
Charles
> Luckily, these can be bitten off in smaller chunks. How would either of you
> experiment with creating the efforts your are suggesting?
> What support is needed? Why would folks be motivated to help or able to see
> what incremental success looks like?
>
> Incidentally, do check out the Code Lounge at IETF 100 as an effort to encourage
> Hackathon-style coding to continue...
>
> Regards,
> Alia
>
> >
> > (for instance, it's particularly difficult to create complex enough
> > infrastructures to test routing protocols such as BGP4, but this also applies
> > to SIDR, S/MIME, OAUTH and even some IPsec setups)
> >
> > Looking up, I see a theme which is really about getting from Proposed
> > Standard to Internet Standard faster and in ways that engages more pieces of
> > the vendor and operational communities.
> >
> > (%)-you may say this is self-serving, and I agree. So I'll just make my
> interest explicit.
> >
> > --
> > Michael Richardson <mcr+IETF@xxxxxxxxxxxx
> <mailto:mcr%2BIETF@xxxxxxxxxxxx>>, Sandelman Software Works
> > -= IPv6 IoT consulting =-
> >
> >
> >
>
>
> --
> Marc Petit-Huguenin
> Email: marc@xxxxxxxxxxxxxxxxxx <mailto:marc@xxxxxxxxxxxxxxxxxx>
> Blog: https://marc.petit-huguenin.org <https://marc.petit-huguenin.org>
> Profile: https://www.linkedin.com/in/petithug
> <https://www.linkedin.com/in/petithug>
>
>
--
Marc Petit-Huguenin
Email: marc@xxxxxxxxxxxxxxxxxx
Blog: https://marc.petit-huguenin.org
Profile: https://www.linkedin.com/in/petithug
------------------------------
Message: 4
Date: Fri, 27 Oct 2017 17:08:31 -0500
From: Spencer Dawkins at IETF <spencerdawkins.ietf@xxxxxxxxx>
To: "Charles Eckel (eckelcu)" <eckelcu@xxxxxxxxx>
Cc: Marc Petit-Huguenin <petithug@xxxxxxx>, Alia Atlas
<akatlas@xxxxxxxxx>, Michael Richardson <mcr+ietf@xxxxxxxxxxxx>, IETF
Discussion Mailing List <ietf@xxxxxxxx>, Doug Royer
<douglasroyer@xxxxxxxxx>, Gonzalo Camarillo
<Gonzalo.Camarillo@xxxxxxxxxxxx>
Subject: Re: Proposal to revise ISOC's mission statement
Message-ID:
<CAKKJt-fanzcuo0=SRS+U9H8HhFQEK+SgRx04bw2i1QQAJdPZCg@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset="utf-8"
FWIW,
On Fri, Oct 27, 2017 at 3:40 PM, Charles Eckel (eckelcu) <eckelcu@xxxxxxxxx>
wrote:
> Overall I think the new mission statement is quite good. One specific
> comment inline.
>
> -----Original Message-----
> From: ietf <ietf-bounces@xxxxxxxx> on behalf of Marc Petit-Huguenin <
> petithug@xxxxxxx>
> Date: Friday, October 27, 2017 at 10:00 AM
> To: Alia Atlas <akatlas@xxxxxxxxx>
> Cc: Doug Royer <douglasroyer@xxxxxxxxx>, Michael Richardson <
> mcr+ietf@xxxxxxxxxxxx>, Gonzalo Camarillo <Gonzalo.Camarillo@xxxxxxxxxxxx>,
> "ietf@xxxxxxxx" <ietf@xxxxxxxx>
> Subject: Re: Proposal to revise ISOC's mission statement
>
> On 10/27/2017 09:46 AM, Alia Atlas wrote:
> > On Fri, Oct 27, 2017 at 12:41 PM, Marc Petit-Huguenin <
> petithug@xxxxxxx
> > <mailto:petithug@xxxxxxx>> wrote:
> >
> > On 10/27/2017 08:40 AM, Michael Richardson wrote:
> > >
> > > Gonzalo Camarillo <Gonzalo.Camarillo@xxxxxxxxxxxx <mailto:
> Gonzalo.Camarillo@xxxxxxxxxxxx>> wrote:
> > > > As you know, ISOC supports the IETF in several ways (in
> addition to
> > > > providing funding). Please, think about how ISOC could
> help support the
> > > > IETF in potentially new ways or how the current programs
> could make an
> > > > even larger impact, and let's have a conversation in
> Singapore. Thanks!
> > >
> > > My take is (in this order);
> > > * longer, more involved Hackathons,
> > > * open source reference implementations (%)
> > > * cheaply and easily reproduceable test bed/skaffolding for
> complex protocols
> > > * facilitating conformance testing, particularly for open
> source implementations.
> >
> > If we are going in that direction then I think it about time
> that the IETF
> > starts using formal methods to verify protocols, so instead of
> partially
> > checking that a protocol works (which is the best that
> hackathons or testing
> > can bring to the table), we have a guarantee that they do work.
> > (self-serving too, as I am working since a couple years on yet
> another
> > markdown language that does exactly that).
> >
> >
> > The wonderful and frustrating thing is that there isn't a single
> activity that
> > will capture all of what would be useful.
>
> Sure, but it would be a good start to have something in the ISOC
> mission statement about promoting protocol checking (hackathon, testing)
> and formal verifications of the IETF standards.
>
> Rather than add more specific examples to the existing set of highlighted
> activities, how about adding something in the mission statement about
> implementation and application in addition to the development of open
> standards. This would leave it to the IETF community to decide on methods
> to achieve this, e.g. more emphasis on running code, reference
> implementations, protocol validation, workshops on enabling new standards
> and functionality, etc.
I think that's just about right.
Spencer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailarchive.ietf.org/arch/browse/ietf/attachments/20171027/518f969f/attachment.html>
------------------------------
Subject: Digest Footer
_______________________________________________
ietf mailing list
ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf
------------------------------
End of ietf Digest, Vol 113, Issue 127
**************************************