Re: [v6ops] Idea about updating RFC3849

[joel jaeggli <[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 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" <[e-mail]>
> To: <[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 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.:  [phone]
>> Fax:   [phone]
>> Email: [e-mail]
>>
>> HRB: 23144, Amtsgericht Montabaur
>> Geschäftsführer: Jens Ott
>> Umsatzsteuer-ID.: DE264133989
> 
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>