Subject: [v6ops] Idea about updating RFC3849

From: "Jens Ott - Opteamax GmbH" <[email-masked]>
Date: Thu, 14 May 2015 10:02:11 +0200

Hi Mailinglist-Members,

I am pretty new on this list, so I first wave a "Hello" into the
round... and immediately continue to ask the question, which led me to
subscribing to this list. Apologies if I chose the wrong list, please
advise me, where to put my question in this case.

I work as consultant and already accompanied several IPv6 roll-outs
from the first idea "we want V6" until production. While
enterprise-setups are mostly /32 or less IPs, I see more and more
rollouts which need much bigger space.

At least in RIPE-Region, each LIR can receive a /29 without any
justification. And here is where my problem starts. While writing
documentation and addressing-plans before requesting the actual prefix
at the appropriate RIR, I'm used to use 2001:db8::/32 as defined in
RFC3849. But what to do for bigger nets (lower bitmasks)?

Before starting to push the ball on the field by writing a proposal,
I'd be happy to hear if there is support in the community for updating
this rfc and officially define a bigger prefix for documentation.

As said, if I chose the wrong mailinglist or simply started bringing
my idea into the community in a wrong way, any advise and comment is
appreciated. I have no experience with the processes at ietf yet.

Best regards and thanks
- -- 
Jens Ott

Opteamax GmbH

Simrockstr. 4b
53619 Rheinbreitbach

Tel.:  +49 2224 969500
Fax:   +49 2224 97691059
Email: [email-masked]

HRB: 23144, Amtsgericht Montabaur
Geschäftsführer: Jens Ott
Umsatzsteuer-ID.: DE264133989

---

From: t.petch <[email-masked]>
Date: Thu, 14 May 2015 17:27:56 +0100

Jens

I think that there might be a slight procedural issue.  The original RFC
was produced by the IPv6 Working Group which is responsible for protocol
changes.  This is the v6ops Working Group which is not allowed to make
protocol changes (but is concerned with making the protocol usable).

It may not be clearcut, but I would see this as a protocol change and so
one that should be discussed and progressed in the IPv6 WG rather than
here.  The WG Chairs will doubtless arbitrate on this.

Otherwise, yes but don't stop at /29; I would go for a /8 and allow
myself to be negotiated back to something in between.
.
Tom Petch

---

From: joel jaeggli <[email-masked]>
Date: Thu, 14 May 2015 10:36:01 -0700

I'm pretty sure that growing the example prefix isn't necessary in order
to that you might use a prefix with a longer or shorter netmask in a
filter.  I wouldn't want to expand it to a /3 just so that I could
express the size of the ipv6unicast address range.

We don't get into existential peril when we refer to ::/0

so if you have to say,  "design the filter this way example my address
space  2001:db8::/32 substituting your prefix and and appropriate length
netmask (shorter or longer as necessary) that doesn't seem excessively
circuitous. and if  they slavishly copy that prefix or netmask well no
harm no foul.

On 5/14/15 9:27 AM, t.petch wrote:
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Mark ZZZ Smith <[email-masked]>
Date: Sat, 16 May 2015 01:16:04 +0000 (UTC)

From: joel jaeggli <[email-masked]>
 To: t.petch <[email-masked]>; Jens Ott - Opteamax GmbH <[email-masked]>; [email-masked] 
 Sent: Friday, 15 May 2015, 3:36
 Subject: Re: [v6ops] Idea about updating RFC3849

/ As the focus of this sort of documentation is the lower order bits, you could probably explain the technique you want to convey of dividing up the lower order bits using 'X'/'x's in place of the upper portion, with the advantage that 'X'/'x's are invalid in IPv6 addresses, and then possibly use the 2001:db8::/32 to demonstrate the technique.

---

From: Jens Ott - Opteamax GmbH <[email-masked]>
Date: Sat, 16 May 2015 13:21:24 +0200

Hi,

extending to /3 is not the idea, but there are lot's of cases where e.g. /16 reserved space would make sense. You'd be surprised, how often people simply copy+paste examples in workshops, actually I was really surprised when I saw 666::/26 in a bunch of looking glasses during a workshop I attended last year.

So obviously filtering seems to be less used as you might think. As long as people use non allocated addressspace, there is no harm and no issue, the project which led me to write this idea, was using actually assigned and active IPs and then harm can occur quickly for the actual owners... you remember the more specific announcements of Google prefixes some month ago?

And yes, I also know that the pure existence of an RFC does not  mean, everybody adopts it, but I am also sure if this existence is promoted a little,  it will reduce the risk of accidentally copy+pasted harm.

BR and have a nice weekend 
Jens

PS: Sorry for tofu, writing on my mobile and for unknown reason my mua did refuse to edit inside quotation.

Am 14. Mai 2015 19:36:01 MESZ, schrieb joel jaeggli <[email-masked]>:
>------------------------------------------------------------------------
>
>!DSPAM:637,5554e2db213971574413910!

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

---

From: "Metzler, Dan J" <[email-masked]>
Date: Sat, 16 May 2015 17:06:29 +0000

Hi,

Admittedly my profession is not documentation, but my initial opinion is something along these lines, if you’re advocating we take more IPv6 address space out of use for documentation.

I don’t think example documentation needs to match exactly, every conceivable prefix length for every possible scenario.  The idea behind examples is to give a general idea, and then if necessary explain that one might use different lengths, perhaps as small as x or as large as y.
There are other types of documentation, that should be taken literally, because specific filters are being documented, or specific networks are being documented.  In those situations, you aren’t using the address space reserved for documentation.

With regard to your specific example:
“While writing documentation and addressing-plans before requesting the actual prefix at the appropriate RIR, I'm used to use 2001:db8::/32 as defined in
RFC3849. But what to do for bigger nets (lower bitmasks)?”
I would just keep doing as you have, but make a note that a /29 would be used instead, if that is your intent, and for the purposes of the example, note that you made all of your prefixes 3 bits longer.  When the actual assignment is made, that’s when you start documenting actual prefix lengths, and move out of the reserved documentation address space.

At a certain point it becomes wasteful to take relatively large amounts of address space out of active use, for use cases like documentation.  Where that line is drawn, is always subjective, and I know it’s IPv6, but I’m sure, at least during my college years, nobody thought we’d ever run out of IPv4 address space either.

Thanks,

-          Dan Metzler

From: v6ops [mailto:[email-masked]] On Behalf Of Jens Ott - Opteamax GmbH
Sent: Saturday, May 16, 2015 6:21 AM
To: joel jaeggli; t.petch; [email-masked]
Subject: Re: [v6ops] Idea about updating RFC3849

Hi,

PS: Sorry for tofu, writing on my mobile and for unknown reason my mua did refuse to edit inside quotation.
Am 14. Mai 2015 19:36:01 MESZ, schrieb joel jaeggli <[email-masked]<mailto:[email-masked]>>:

 Jens

 I think that there might be a slight procedural issue.  The original RFC
 was produced by the IPv6 Wo!

 rking

Group which is responsible for protocol
 changes.  This is the v6ops Working Group which is not allowed to make
 protocol changes (but is concerned with making the protocol usable).

 ----- Original Message -----
 From: "Jens Ott - Opteamax GmbH" <[email-masked]<mailto:[email-masked]>>
 To: <[email-masked]<mailto:[email-masked]>>
 Sent: Thursday, May 14, 2015 9:02 AM
 Subject: [v6ops] Idea about updating RFC3849

 Hi Mailinglist-Members,

 I am!

  pretty

new on this list, so I first wave a "Hello" into the
 round... and immediately continue to ask the question, which led me to
 subscribing to this list. Apologies if I chose the wrong list, please
 advise me, where to put my question in this case.

 I'd be happy to h!

 ear if

there is support in the community for updating
 this rfc and officially define a bigger prefix for documentation.

 Best regards and thanks
 - --
 Jens Ott

 Opteamax GmbH

 Simrockstr. 4b
 53619 Rheinbreitbach

 Tel.:  +49 2224 969500
 Fax:   +49 2224 97691059
 Email: [email-masked]<mailto:[email-masked]>

________________________________

 v6ops mailing list
 [email-masked]<mailto:[email-masked]>
 https://www.ietf.org/mailman/listinfo/v6ops

---

From: tom petch <[email-masked]>
Date: Sun, 17 May 2015 09:14:56 +0100

----- Original Message ----- 
  From: Jens Ott - Opteamax GmbH 
  To: joel jaeggli ; t.petch ; [email-masked] 
  Sent: Saturday, May 16, 2015 12:21 PM

  Hi,

  <tp>

  Yes, that is what drove my reply.  I still recall teaching how to renumber to a customer whose predecessor had been on a course which had not used documentation prefixes and so had incorporated someone else's public IP addresses into their organisation.  Which worked fine for a while and then they connected to the Internet.

  So yes, the examples in a workshop should match reality as closely as possible, so that, in effect, when the student is back in the real world, all they have to do is a global change, not try to remember when /48 becomes /64 or /36 becomes /29.
  Tom Petch

  p.s. different e-mail client, heaven knows what this will look like

  p.p.s. and I still think that this is one for IPv6 not v6ops

  Am 14. Mai 2015 19:36:01 MESZ, schrieb joel jaeggli <[email-masked]>:
I'm pretty sure that growing the example prefix isn't necessary in orderto that you might use a prefix with a longer or shorter netmask in afilter.  I wouldn't want to expand it to a /3 just so that I couldexpress the size of the ipv6unicast address range.We don't get into existential peril when we refer to ::/0so if you have to say,  "design the filter this way example my addressspace  2001:db8::/32 substituting your prefix and and appropriate lengthnetmask (shorter or longer as necessary) that doesn't seem excessivelycircuitous. and if  they slavishly copy that prefix or netmask well noharm no foul.On 5/14/15 9:27 AM, t.petch wrote: Jens  I think that there might be a slight procedural issue.  The original RFC was produced by the IPv6 Working
Group which is responsible for protocol changes.  This is the v6ops Working Group which is not allowed to make protocol changes (but is concerned with making the protocol usable).  It may not be clearcut, but I would see this as a protocol change and so one that should be discussed and progressed in the IPv6 WG rather than here.  The WG Chairs will doubtless arbitrate on this.  Otherwise, yes but don't stop at /29; I would go for a /8 and allow myself to be negotiated back to something in between. . Tom Petch   ----- Original Message ----- From: "Jens Ott - Opteamax GmbH" <[email-masked]> To: <[email-masked]> Sent: Thursday, May 14, 2015 9:02 AM Subject: [v6ops] Idea about updating RFC3849 Hi Mailinglist-Members, I am pretty
new on this list, so I first wave a "Hello" into the round... and immediately continue to ask the question, which led me to subscribing to this list. Apologies if I chose the wrong list, please advise me, where to put my question in this case. I work as consultant and already accompanied several IPv6 roll-outs from the first idea "we want V6" until production. While enterprise-setups are mostly /32 or less IPs, I see more and more rollouts which need much bigger space. At least in RIPE-Region, each LIR can receive a /29 without any justification. And here is where my problem starts. While writing documentation and addressing-plans before requesting the actual prefix at the appropriate RIR, I'm used to use 2001:db8::/32 as defined in RFC3849. But what to do for bigger nets (lower bitmasks)? Before starting to push the ball on the field by writing a proposal, I'd be happy to hear if
there is support in the community for updating this rfc and officially define a bigger prefix for documentation. As said, if I chose the wrong mailinglist or simply started bringing my idea into the community in a wrong way, any advise and comment is appreciated. I have no experience with the processes at ietf yet. Best regards and thanks - -- Jens Ott Opteamax GmbH Simrockstr. 4b 53619 Rheinbreitbach Tel.:  +49 2224 969500 Fax:   +49 2224 97691059 Email: [email-masked] HRB: 23144, Amtsgericht Montabaur Geschäftsführer: Jens Ott Umsatzsteuer-ID.: DE264133989 -------------------------------------------------------------------------- v6ops mailing list [email-masked] https://www.ietf.org/mailman/listinfo/v6ops 
!DSPAM:637,5554e2db213971574413910!
  -- 
  Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.