[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf
Subject:    Re: IP's for point-to-point and loopbacks
From:       Junior Corazza <corazza () incert ! com ! br>
Date:       2017-10-28 1:19:54
Message-ID: 1CED869D-B1D2-43DC-9A52-A39B4F26D1A4 () incert ! com ! br
[Download RAW message or body]

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@ietf.org em nome de ietf-request@ietf.org" \
<ietf-bounces@ietf.org em nome de ietf-request@ietf.org> escreveu:

    Send ietf mailing list submissions to
    	ietf@ietf.org
    
    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@ietf.org
    
    You can reach the person managing the list at
    	ietf-owner@ietf.org
    
    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@gmail.com>
    To: ietf@ietf.org
    Subject: Re: IP's for point-to-point and loopbacks
    Message-ID: <3a41b5f8-b711-cc27-d9ca-f75e7ba48da0@gmail.com>
    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@nohats.ca>
    To: Brian E Carpenter <brian.e.carpenter@gmail.com>
    Cc: ietf@ietf.org
    Subject: Re: IP's for point-to-point and loopbacks
    Message-ID: <B7EE2A70-3433-4030-A01A-EC871C78E68E@nohats.ca>
    Content-Type: text/plain;	charset=utf-8
    
    On Oct 27, 2017, at 23:35, Brian E Carpenter <brian.e.carpenter@gmail.com> 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@cisco.com>
    To: Marc Petit-Huguenin <petithug@acm.org>, Alia Atlas
    	<akatlas@gmail.com>
    Cc: Doug Royer <douglasroyer@gmail.com>, Michael Richardson
    	<mcr+ietf@sandelman.ca>, Gonzalo Camarillo
    	<Gonzalo.Camarillo@ericsson.com>, IETF Discussion Mailing List
    	<ietf@ietf.org>
    Subject: Re: Proposal to revise ISOC's mission statement
    Message-ID: <CBF4104B-2DEF-4F88-AD9F-59996CB58735@cisco.com>
    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@ietf.org> on behalf of Marc Petit-Huguenin \
<petithug@acm.org>  Date: Friday, October 27, 2017 at 10:00 AM
    To: Alia Atlas <akatlas@gmail.com>
    Cc: Doug Royer <douglasroyer@gmail.com>, Michael Richardson \
<mcr+ietf@sandelman.ca>, Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>, \
"ietf@ietf.org" <ietf@ietf.org>  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@acm.org 
        > <mailto:petithug@acm.org>> wrote:
        > 
        >     On 10/27/2017 08:40 AM, Michael Richardson wrote:
        >     >
        >     > Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com \
                <mailto:Gonzalo.Camarillo@ericsson.com>> 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@sandelman.ca
        >     <mailto:mcr%2BIETF@sandelman.ca>>, Sandelman Software Works
        >      >  -= IPv6 IoT consulting =-
        >      >
        >      >
        >      >
        > 
        > 
        >     --
        >     Marc Petit-Huguenin
        >     Email: marc@petit-huguenin.org <mailto:marc@petit-huguenin.org>
        >     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@petit-huguenin.org
        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@gmail.com>
    To: "Charles Eckel (eckelcu)" <eckelcu@cisco.com>
    Cc: Marc Petit-Huguenin <petithug@acm.org>, Alia Atlas
    	<akatlas@gmail.com>,  Michael Richardson <mcr+ietf@sandelman.ca>, IETF
    	Discussion Mailing List <ietf@ietf.org>,  Doug Royer
    	<douglasroyer@gmail.com>, Gonzalo Camarillo
    	<Gonzalo.Camarillo@ericsson.com>
    Subject: Re: Proposal to revise ISOC's mission statement
    Message-ID:
    	<CAKKJt-fanzcuo0=SRS+U9H8HhFQEK+SgRx04bw2i1QQAJdPZCg@mail.gmail.com>
    Content-Type: text/plain; charset="utf-8"
    
    FWIW,
    
    On Fri, Oct 27, 2017 at 3:40 PM, Charles Eckel (eckelcu) <eckelcu@cisco.com>
    wrote:
    
    > Overall I think the new mission statement is quite good. One specific
    > comment inline.
    >
    > -----Original Message-----
    > From: ietf <ietf-bounces@ietf.org> on behalf of Marc Petit-Huguenin <
    > petithug@acm.org>
    > Date: Friday, October 27, 2017 at 10:00 AM
    > To: Alia Atlas <akatlas@gmail.com>
    > Cc: Doug Royer <douglasroyer@gmail.com>, Michael Richardson <
    > mcr+ietf@sandelman.ca>, Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>,
    > "ietf@ietf.org" <ietf@ietf.org>
    > 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@acm.org
    >     > <mailto:petithug@acm.org>> wrote:
    >     >
    >     >     On 10/27/2017 08:40 AM, Michael Richardson wrote:
    >     >     >
    >     >     > Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com <mailto:
    > Gonzalo.Camarillo@ericsson.com>> 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@ietf.org
    https://www.ietf.org/mailman/listinfo/ietf
    
    
    ------------------------------
    
    End of ietf Digest, Vol 113, Issue 127
    **************************************
    


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic