Re: [v6ops] Idea about updating RFC3849

["Metzler, Dan J" <[e-mail]>]

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:[e-mail]] On Behalf Of Jens Ott - Opteamax GmbH
Sent: Saturday, May 16, 2015 6:21 AM
To: joel jaeggli; t.petch; [e-mail]
Subject: Re: [v6ops] Idea about updating RFC3849

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 <[e-mail]<mailto:[e-mail]>>:

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:

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

 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" <[e-mail]<mailto:[e-mail]>>
 To: <[e-mail]<mailto:[e-mail]>>
 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 h!

 ear 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.:  [phone]
 Fax:   [phone]
 Email: [e-mail]<mailto:[e-mail]>

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



________________________________

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




!DSPAM:637,5554e2db213971574413910!

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