[ipv6-wg] ipv6-wg Digest, Vol 26, Issue 13

I read the presentation; It has some benefits and some problems.
This kind of IPv6 addressing maybe decrease network security
and it will give opportunity to hackers to access to the special networks by
special IPv6 address scanning.
Thank you
Behrouz 


________________________________
 From: "ipv6-wg-request at ripe.net" <ipv6-wg-request at ripe.net>
To: ipv6-wg at ripe.net 
Sent: Sunday, October 27, 2013 2:30 PM
Subject: ipv6-wg Digest, Vol 26, Issue 13
 

Send ipv6-wg mailing list submissions to
    ipv6-wg at ripe.net

To subscribe or unsubscribe via the World Wide Web, visit
    https://www.ripe.net/mailman/listinfo/ipv6-wg
or, via email, send a message with subject or body 'help' to
    ipv6-wg-request at ripe.net

You can reach the person managing the list at
    ipv6-wg-owner at ripe.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of ipv6-wg digest..."


Today's Topics:

   1. Re: 96 more bits... time for some magic after all?
      (Yannis Nikolopoulos)
   2. Re: 96 more bits... time for some magic after all?
      (Benedikt Stockebrand)
   3. Re: 96 more bits... time for some magic after all?
      (Yannis Nikolopoulos)


----------------------------------------------------------------------

Message: 1
Date: Sat, 26 Oct 2013 15:52:34 +0300
From: Yannis Nikolopoulos <dez at otenet.gr>
Subject: Re: [ipv6-wg] 96 more bits... time for some magic after all?
To: ipv6-wg at ripe.net
Message-ID: <526BBB12.1090705 at otenet.gr>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Hello,

On 10/25/2013 06:53 PM, S.P.Zeidler wrote:
> Thus wrote Shane Kerr (shane at time-travellers.org):
>
>> We saw two presentations by network architects at the RIPE meeting that
>> used bits in their IPv6 addressing plan to carry meaning beyond simple
>> network topology and packet routing.
>>
>> For example, declaring a specific bit in the address to be 1 for voice
>> traffic or 0 otherwise.
> [...]
>
>> What should we do about it?
> As a RIR, nothing.

what about as one of RIPE's WGs? Should we go on and produce a BCP 
document of some kind? As the author of this addressing plan

(https://ripe67.ripe.net/presentations/222-ripe67-yanodd-ipv6-addressing.pdf) , my main motivation for presenting it was to show that it is possible to encode basic information in an addressing plan (without wasting too much space) and still keep it simple . For example, even IPv4 addressing plans were location-aware, that's nothing new. Well, its even easier and more effective in IPv6 addressing, because of the number of bits available. As far as encoding service type, no space is wasted because it is encoded after the /56 boundary ;) , even making it possible for QOS.

As I mentioned in the presentation, this is our 3rd or 4th try over the past ~10 years. So far, with the help of some basic heuristics, it seems to be working out fine


cheers,
Yannis

>
> Otherwise: violations of the KISS principle are rarely a good idea.
> In this case, you might find out that you snuck yourself into a
> straightjacket a few years down the line.
>
> regards,
>     spz




------------------------------

Message: 2
Date: Sun, 27 Oct 2013 07:54:42 +0000
From: Benedikt Stockebrand <bs at stepladder-it.com>
Subject: Re: [ipv6-wg] 96 more bits... time for some magic after all?
To: Roger J?rgensen <rogerj at gmail.com>
Cc: "ipv6-wg at ripe.net IPv6" <ipv6-wg at ripe.net>
Message-ID: <87ob6bkv25.fsf at stepladder-it.com>
Content-Type: text/plain; charset=utf-8

Hi Roger and list,

On Fri, Roger J?rgensen <rogerj at gmail.com> writes:

>  Oct 25, 2013 at 5:24 PM, Benedikt Stockebrand
> <bs at stepladder-it.com> wrote:
>> [...]
>> More important however is the question how to deal with them if /when
>> they show up because they have unnecessarily "depleted" their address
>> assignment thanks to encoding stuff in it.
>> [...]
> If they run out due to size and growth, and they haven't wasted space,
> used their available /29 wisely by every advice given...give them
> another prefix.

That's what I meant by "unnecessarily 'depleted'".  If they actually
grow beyond their /29 or whatever, let them have another prefix.

What I wouldn't want to see however is that some big player gets some
extra address space because they wasted their existing one.  Once that
happens, everyone will demand the same.

And yes, I've had these discussions.  In particular, the idea to
bit-encode the services (i.e. significant port numbers) somewhere in the
subnet prefix.  Eventually these people decided "well, we have a /12 for
IPv4, so it's only fair we also get a /12 for IPv6".  At that point I
pretty much gave up and told them to request that from their RIR...

> One way to waste is to give every single customer a /48 when you are
> really really big. /56 work just fine really, even for techies like me :)

Sorry, but I disagree on that.  A /56 is fine for today's requirements,
but if this hype about the "Internet of Things" really takes off and you
want to put things into different subnets, a /56 may occasionally be a
problem even for consumer households.  Not today, but think anything
from ten to fourty years.

> However IPv6 is big enough that most people will not feel any pain with
> it, some however will start to get into trouble in 5-10years time, guess
> more like around in 7 years. The reason? They made a too static model
> on how they wanted to use their available space.

Agreed, but...

> But you have to be big to get into that trouble.

I don't see any reason why size has to do with it.  The problem is more
of a ratio between size and allocated address space---and the technical
knowledge around.  (And no, unlike somebody else on this list I don't
believe it feasible for a consumer to call in a CCIE every time they
need some networked deviced hooked up.)

> There was major discussion just to get that /56 into the documents.
> Upto that point there was /64 pr.LAN, /48 for the rest. Now we're relaxing
> it even more. Are discussion on moving away from /64's on the wire to...

If /64 is given up, all sorts of shit will happen.  It has been part of
the specs for long enough that a number of implementations will rely on
it.  It's not just autoconfiguration, but when it comes to embedded
system/microcontroller implementations, changing that is rather
difficult.

Additionally, anything that can be (mis-)configured exponentially adds
(or rather, multiplies) to the frustration potential for end users.

> Doesn't this sound like A/B/C-class network vs CIDR?

You mean VLSM, I assume?

> * For one server running in the cloud I got a /112, that work just fine really.

...until you do an upgrade on the server that relies on RFC 4291.

> * Somewhere else I'm using a /50 on the wire, that also work just fine.

Same issue.  Yes, at least some implementations support that right now,
but you shouldn't rely on that.  Additionally, for whoever may have to
run that system further later on you set up some ugly surprise that way.

> * I have tried to use an entire /48 but failed. I tried to build my
> own network with VPN, routings and everything across the different
> servers and routers I have spread around. That /48 was big enough for
> me:)

Oha.  So you have too many machines to fit into a /64 in a single
subnet?

> * I tried to build a big routed, multisite network using a /56, that
> also worked upto a certain size :)

Sorry, I don't get what you want to say there.


Cheers,

    Benedikt

-- 
             Business Grade IPv6
            Consulting, Training, Projects

Benedikt Stockebrand, Dipl.-Inform.        http://www.stepladder-it.com/



------------------------------

Message: 3
Date: Sun, 27 Oct 2013 12:02:46 +0200
From: Yannis Nikolopoulos <dez at otenet.gr>
Subject: Re: [ipv6-wg] 96 more bits... time for some magic after all?
To: Benedikt Stockebrand <bs at stepladder-it.com>
Cc: "ipv6-wg at ripe.net IPv6" <ipv6-wg at ripe.net>
Message-ID: <526CE4C6.9060003 at otenet.gr>
Content-Type: text/plain; charset=UTF-8; format=flowed

On 10/27/2013 09:54 AM, Benedikt Stockebrand wrote:
> Hi Roger and list,
>
> On Fri, Roger J?rgensen <rogerj at gmail.com> writes:
>
>>   Oct 25, 2013 at 5:24 PM, Benedikt Stockebrand
>> <bs at stepladder-it.com> wrote:
>> What I wouldn't want to see however is that some big player gets some 
>> extra address space because they wasted their existing one. Once that 
>> happens, everyone will demand the same. 

that's the second time I read this in this thread. Why would this 
happen? All allocations are subject to RIR policy

>> One way to waste is to give every single customer a /48 when you are
>> really really big. /56 work just fine really, even for techies like me :)
> Sorry, but I disagree on that.  A /56 is fine for today's requirements,
> but if this hype about the "Internet of Things" really takes off and you
> want to put things into different subnets, a /56 may occasionally be a
> problem even for consumer households.  Not today, but think anything
> from ten to fourty years.

40 years from now? Many, more significant changes will probably 
overshadow this. Otherwise, 256 different policies in a home sound just fine

>
>> There was major discussion just to get that /56 into the documents.
>> Upto that point there was /64 pr.LAN, /48 for the rest. Now we're relaxing
>> it even more. Are discussion on moving away from /64's on the wire to...
> It's not just autoconfiguration, but when it comes to embedded
> system/microcontroller implementations, changing that is rather
> difficult.

care to elaborate on that?

>> * For one server running in the cloud I got a /112, that work just fine really.
> ...until you do an upgrade on the server that relies on RFC 4291.
>
>> * Somewhere else I'm using a /50 on the wire, that also work just fine.
> Same issue.  Yes, at least some implementations support that right now,
> but you shouldn't rely on that.  Additionally, for whoever may have to
> run that system further later on you set up some ugly surprise that way.

again, care to elaborate a bit? How's a /50 not compliant with RFC 4291?

> Cheers, Benedikt 

cheers,
Yannis



End of ipv6-wg Digest, Vol 26, Issue 13
***************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ripe.net/ripe/mail/archives/ipv6-wg/attachments/20131104/5cdce071/attachment.html>