IPv6 Loopback/Point-to-Point address allocation
All, I’ve been doing some reading in preparation of IPv6 deployment and figuring out how we will break up our /32. I think I’m on the right track in thinking that each customer will be allocated a /48 to do whatever they wish with it. I’ve read recent BCOP drafts that have been approved by the IETF: https://www.ripe.net/publications/docs/ripe-554 It looks like the smallest subnet that should ever be assigned is a /64 on a particular link. Some questions that come to mind with IPv6: In regards to Point to point links my thinking is this: Assign a unique /64 to each point to point link with these addresses being Globally routable. This seems to be what our IX providers do when assigning us an IPv6 address. Am I correct in this train of thought? Why/Why not? In regards to core loopback addressing my initial thoughts are as follows: Assign a single /64 encompassing all /128’s planned for loopback addressing schemes. Should I be using Unique Local addressing for loopbacks instead of going with a Globally routeable addressing scheme? Should each interface IP configuration have a /64 or a /128? Also when talking about CPE mgmt addresses what do you think is a practical way of going about assigning “Private” addressing schemes for cpe management purposes. I’m sure some of these questions will be answered when I dive deeper into how OSPFv6 works as well as BGP in regards to IPv6. Are any of you currently running IPv6 and wished you had done something differently during the planning phase that may have prevented headaches down the road? Kody Vicknair Network Engineer [cid:imagebf3343.JPG@c9d2fbd2.4db10e0d] <http://www.rtconline.com> Tel: 985.536.1214 Fax: 985.536.0300 Email: kvicknair@reservetele.com Web: www.rtconline.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Kody Vicknair immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Kody Vicknair therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission.
You want to configure point to point interfaces as /127 or /126 even if you allocate a full /64 for the link. This prevents an NDP exhaustion attack with no downside. Loopback interfaces should be configured as /128. How you allocate these do not matter. Den 9. sep. 2017 18.08 skrev "Kody Vicknair" <kvicknair@reservetele.com>:
All,
I’ve been doing some reading in preparation of IPv6 deployment and figuring out how we will break up our /32. I think I’m on the right track in thinking that each customer will be allocated a /48 to do whatever they wish with it.
I’ve read recent BCOP drafts that have been approved by the IETF: https://www.ripe.net/publications/docs/ripe-554 It looks like the smallest subnet that should ever be assigned is a /64 on a particular link.
Some questions that come to mind with IPv6:
In regards to Point to point links my thinking is this: Assign a unique /64 to each point to point link with these addresses being Globally routable. This seems to be what our IX providers do when assigning us an IPv6 address. Am I correct in this train of thought? Why/Why not?
In regards to core loopback addressing my initial thoughts are as follows: Assign a single /64 encompassing all /128’s planned for loopback addressing schemes. Should I be using Unique Local addressing for loopbacks instead of going with a Globally routeable addressing scheme? Should each interface IP configuration have a /64 or a /128?
Also when talking about CPE mgmt addresses what do you think is a practical way of going about assigning “Private” addressing schemes for cpe management purposes.
I’m sure some of these questions will be answered when I dive deeper into how OSPFv6 works as well as BGP in regards to IPv6.
Are any of you currently running IPv6 and wished you had done something differently during the planning phase that may have prevented headaches down the road?
Kody Vicknair Network Engineer
[cid:imagebf3343.JPG@c9d2fbd2.4db10e0d] <http://www.rtconline.com>
Tel: 985.536.1214 Fax: 985.536.0300 Email: kvicknair@reservetele.com Web: www.rtconline.com
Reserve Telecommunications 100 RTC Dr Reserve, LA 70084
Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Kody Vicknair immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Kody Vicknair therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission.
Hi, On Sun, Sep 10, 2017 at 10:47:05AM +0100, Nick Hilliard wrote:
Baldur Norddahl wrote:
Loopback interfaces should be configured as /128. How you allocate these do not matter.
..so long as there are interface ACLs on your network edge which block direct IP access to these IP addresses.
or, maybe even more efficient, assign all loopbacks from a dedicated netblock which you null-route on the edge/your border devices. best Enno -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Matthias Luft, Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator =======================================================
Hi, On Sun, Sep 10, 2017 at 11:53:20AM +0200, Enno Rey wrote:
On Sun, Sep 10, 2017 at 10:47:05AM +0100, Nick Hilliard wrote:
Baldur Norddahl wrote:
Loopback interfaces should be configured as /128. How you allocate these do not matter.
..so long as there are interface ACLs on your network edge which block direct IP access to these IP addresses.
or, maybe even more efficient, assign all loopbacks from a dedicated netblock which you null-route on the edge/your border devices.
Null-routing may not be sufficient, if the edge/border router has a route to that /128; the (forwardable) /128 entry will win from the blackholed /64 FIB entry since it is more-specific. Applying an ingress interface ACL to each and every external facing interface will probably work best in the most common deployment scenarios. For router-to-router linknets I recommend to configure a linknet that is as small as possible and is supported by all sides: /127, /126, /120, etc. Some vendors have put in effort to mitigate the problems related to Neighbor Discovery Protocol cache exhaustion attacks, but the fact of the matter is that on small subnets like a /127, /126 or /120 such attacks simply are non-existent. Kind regards, Job
Hi, On Sun, Sep 10, 2017 at 12:08:59PM +0200, Job Snijders wrote:
Hi,
On Sun, Sep 10, 2017 at 11:53:20AM +0200, Enno Rey wrote:
On Sun, Sep 10, 2017 at 10:47:05AM +0100, Nick Hilliard wrote:
Baldur Norddahl wrote:
Loopback interfaces should be configured as /128. How you allocate these do not matter.
..so long as there are interface ACLs on your network edge which block direct IP access to these IP addresses.
or, maybe even more efficient, assign all loopbacks from a dedicated netblock which you null-route on the edge/your border devices.
Null-routing may not be sufficient, if the edge/border router has a route to that /128
good point. I was coming from an Enterprise network perspective where - the border devices do not necessarily hold the/those 128(s) given there's a layer of stateful firewalls in between which creates an isolation boundary for routing protocols. - people do not necessarily fully trust the (outsourced) entities responsible for implementing the filters/ACLs. - this is hence a not-uncommon strategy to feel/be safer as for the (unwanted) global reachability of loopbacks, after the introduction of IPv6. best Enno ; the (forwardable) /128 entry will win from the
blackholed /64 FIB entry since it is more-specific. Applying an ingress interface ACL to each and every external facing interface will probably work best in the most common deployment scenarios.
For router-to-router linknets I recommend to configure a linknet that is as small as possible and is supported by all sides: /127, /126, /120, etc. Some vendors have put in effort to mitigate the problems related to Neighbor Discovery Protocol cache exhaustion attacks, but the fact of the matter is that on small subnets like a /127, /126 or /120 such attacks simply are non-existent.
Kind regards,
Job
-- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Matthias Luft, Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator =======================================================
Hi, On Sun, Sep 10, 2017 at 12:08:59PM +0200, Job Snijders wrote:
Hi,
On Sun, Sep 10, 2017 at 11:53:20AM +0200, Enno Rey wrote:
On Sun, Sep 10, 2017 at 10:47:05AM +0100, Nick Hilliard wrote:
Baldur Norddahl wrote:
Loopback interfaces should be configured as /128. How you allocate these do not matter.
..so long as there are interface ACLs on your network edge which block direct IP access to these IP addresses.
or, maybe even more efficient, assign all loopbacks from a dedicated netblock which you null-route on the edge/your border devices.
Null-routing may not be sufficient, if the edge/border router has a route to that /128; the (forwardable) /128 entry will win from the blackholed /64 FIB entry since it is more-specific.
just thought about it a bit. As mentioned (in other post) I was thinking of a specific use case/setting, but wouldn't a static null-route (of a blackholed /64) win over a /128 learned from a RP anyway (given the better AD)? Am I missing sth here? thanks Enno Applying an ingress
interface ACL to each and every external facing interface will probably work best in the most common deployment scenarios.
For router-to-router linknets I recommend to configure a linknet that is as small as possible and is supported by all sides: /127, /126, /120, etc. Some vendors have put in effort to mitigate the problems related to Neighbor Discovery Protocol cache exhaustion attacks, but the fact of the matter is that on small subnets like a /127, /126 or /120 such attacks simply are non-existent.
Kind regards,
Job
-- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Matthias Luft, Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator =======================================================
Null-routing may not be sufficient, if the edge/border router has a route to that /128; the (forwardable) /128 entry will win from the blackholed /64 FIB entry since it is more-specific.
just thought about it a bit. As mentioned (in other post) I was thinking of a specific use case/setting, but wouldn't a static null-route (of a blackholed /64) win over a /128 learned from a RP anyway (given the better AD)? Am I missing sth here?
Longest prefix match wins. Steinar Haug, Nethelp consulting, sthaug@nethelp.no
On 2017-09-10 00:09, Baldur Norddahl wrote:
You want to configure point to point interfaces as /127 or /126 even if you allocate a full /64 for the link. This prevents an NDP exhaustion attack with no downside.
An alternative is to just have link-local addresses on your point-to- point links. At least on your internal links where you run your IGP. On external links, where you run eBGP or static routes, it's probably more trouble than it is worth, though, since link-local addresses can change if you replace the hardware, requiring a config change on the other end. (Also, I'm not sure all BGP implementations support using link-local addresses.) /Bellman
On 10 September 2017 at 13:56, Thomas Bellman <bellman@nsc.liu.se> wrote:
An alternative is to just have link-local addresses on your point-to- point links. At least on your internal links where you run your IGP. On external links, where you run eBGP or static routes, it's probably more trouble than it is worth, though, since link-local addresses can change if you replace the hardware, requiring a config change on the other end. (Also, I'm not sure all BGP implementations support using link-local addresses.)
This is solvable problem. Vendors support 'bgp listen' or 'bgp allow' to accept BGP session from specific CIDR range. Similarly you could allow IPv6 on interface, with SADDR anywhere in link-local. Your own end link-local stability you could guarantee by manually configuring MAC address, instead of using BIA. I.e. customers would experience stable DADDR, but we wouldn't care about customer's SADDR. However I don't think market would generally appreciate the implications linklocal brings to traceroute, where least bad option would be just to originate hop-limit exceeded from loop0, with no visibility on actual interface. -- ++ytti
Hi, On Sun, Sep 10, 2017 at 02:25:04PM +0300, Saku Ytti wrote:
On 10 September 2017 at 13:56, Thomas Bellman <bellman@nsc.liu.se> wrote:
An alternative is to just have link-local addresses on your point-to- point links. At least on your internal links where you run your IGP. On external links, where you run eBGP or static routes, it's probably more trouble than it is worth, though, since link-local addresses can change if you replace the hardware, requiring a config change on the other end. (Also, I'm not sure all BGP implementations support using link-local addresses.)
all BGP implementations I'm aware of do that (support LLAs), BUT at least Cisco's doesn't support using the same LLAs in multiple BGP sessions (e.g. on PE-CE links) which in turn ruins the potential benefits in many environments, see https://ripe72.ripe.net/presentations/122-ERNW_RIPE72_IPv6wg_RFC7404.pdf https://blog.apnic.net/2016/05/31/beauty-ipv6-link-local-addressing-not/
This is solvable problem. Vendors support 'bgp listen' or 'bgp allow' to accept BGP session from specific CIDR range. Similarly you could allow IPv6 on interface, with SADDR anywhere in link-local. Your own end link-local stability you could guarantee by manually configuring MAC address, instead of using BIA. I.e. customers would experience stable DADDR, but we wouldn't care about customer's SADDR.
However I don't think market would generally appreciate the implications linklocal brings to traceroute, where least bad option would be just to originate hop-limit exceeded from loop0, with no visibility on actual interface.
some might be willing to accept that, as a trade-off for other benefits operations-wise. best Enno -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Matthias Luft, Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator =======================================================
On 10/09/2017 14:25, Saku Ytti wrote:
However I don't think market would generally appreciate the implications linklocal brings to traceroute, where least bad option would be just to originate hop-limit exceeded from loop0, with no visibility on actual interface.
rfc5837 would help but it seems market universally ignore it for some reason unknown to me (lack of interest and IPv6 adoption?) We find LL is simpler, operation wise at some cases.
On Sep 11, 2017, at 3:35 AM, Nikolay Shopik <shopik+lists@nvcube.net> wrote:
On 10/09/2017 14:25, Saku Ytti wrote:
However I don't think market would generally appreciate the implications linklocal brings to traceroute, where least bad option would be just to originate hop-limit exceeded from loop0, with no visibility on actual interface.
rfc5837 would help but it seems market universally ignore it for some reason unknown to me (lack of interest and IPv6 adoption?)
We find LL is simpler, operation wise at some cases.
How’s that work out for you on routers with the same MAC address on multiple interfaces when you’re trying to troubleshoot ECMP trace routes? Owen
I don't see any point of using larger Network space for point to point links or on loopback addresses. To me the best is that 127-Bit prefixes on IPv6 point-to-point links and /128 on Loopback serves the purpose, and offers us a lot of advantages such as it prevents us from neighbor discovery exhaustion attack (rfc6583) Draft is mainly referring to end user WAN links (i.e. xDSL, Cable, FTTN/H) and that's a different story where /64 /56 /48 are still open to dispute :P On Sat, Sep 9, 2017 at 9:06 AM, Kody Vicknair <kvicknair@reservetele.com> wrote:
All,
I’ve been doing some reading in preparation of IPv6 deployment and figuring out how we will break up our /32. I think I’m on the right track in thinking that each customer will be allocated a /48 to do whatever they wish with it.
I’ve read recent BCOP drafts that have been approved by the IETF: https://www.ripe.net/publications/docs/ripe-554 It looks like the smallest subnet that should ever be assigned is a /64 on a particular link.
Some questions that come to mind with IPv6:
In regards to Point to point links my thinking is this: Assign a unique /64 to each point to point link with these addresses being Globally routable. This seems to be what our IX providers do when assigning us an IPv6 address. Am I correct in this train of thought? Why/Why not?
In regards to core loopback addressing my initial thoughts are as follows: Assign a single /64 encompassing all /128’s planned for loopback addressing schemes. Should I be using Unique Local addressing for loopbacks instead of going with a Globally routeable addressing scheme? Should each interface IP configuration have a /64 or a /128?
Also when talking about CPE mgmt addresses what do you think is a practical way of going about assigning “Private” addressing schemes for cpe management purposes.
I’m sure some of these questions will be answered when I dive deeper into how OSPFv6 works as well as BGP in regards to IPv6.
Are any of you currently running IPv6 and wished you had done something differently during the planning phase that may have prevented headaches down the road?
Kody Vicknair Network Engineer
[cid:imagebf3343.JPG@c9d2fbd2.4db10e0d] <http://www.rtconline.com>
Tel: 985.536.1214 Fax: 985.536.0300 Email: kvicknair@reservetele.com Web: www.rtconline.com
Reserve Telecommunications 100 RTC Dr Reserve, LA 70084
Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Kody Vicknair immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Kody Vicknair therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission.
On Sep 9, 2017, at 12:06 PM, Kody Vicknair <kvicknair@reservetele.com> wrote:
All,
I’ve been doing some reading in preparation of IPv6 deployment and figuring out how we will break up our /32. I think I’m on the right track in thinking that each customer will be allocated a /48 to do whatever they wish with it.
Yes, please. If it turns out a /32 isn’t enough space to do this, then a /32 is too small for your network and you should trade it for a larger block.
I’ve read recent BCOP drafts that have been approved by the IETF: https://www.ripe.net/publications/docs/ripe-554 It looks like the smallest subnet that should ever be assigned is a /64 on a particular link.
Some questions that come to mind with IPv6:
In regards to Point to point links my thinking is this: Assign a unique /64 to each point to point link with these addresses being Globally routable. This seems to be what our IX providers do when assigning us an IPv6 address. Am I correct in this train of thought? Why/Why not?
Yes and no. An IX is usually _NOT_ a point to point, but a layer 2 fabric much like a LAN except that it connects a bunch of different ASNs. Still assigning a /64 to point to points makes a lot of sense, even if you use them as /127s on the link.
In regards to core loopback addressing my initial thoughts are as follows: Assign a single /64 encompassing all /128’s planned for loopback addressing schemes. Should I be using Unique Local addressing for loopbacks instead of going with a Globally routeable addressing scheme? Should each interface IP configuration have a /64 or a /128?
I prefer GUA. These might show up in traceroutes. Each LO interface should have a /128. There’s no point (in most situations) in giving anything more).
Also when talking about CPE mgmt addresses what do you think is a practical way of going about assigning “Private” addressing schemes for cpe management purposes.
That’s way too open ended to provide useful advice. It really depends on your particular situation, topology, political limitations, and more.
I’m sure some of these questions will be answered when I dive deeper into how OSPFv6 works as well as BGP in regards to IPv6.
99.9% they work just like in IPv4.
Are any of you currently running IPv6 and wished you had done something differently during the planning phase that may have prevented headaches down the road?
Sounds like you’re generally on the right track. You may want to look in the archives for the NANOG on the Road in Las Vegas. I gave an Address Planning talk there and the slides should be online. If you’re anywhere near Cambridge, MA Thursday, I’ll be doing it again there. Owen
Kody Vicknair Network Engineer
[cid:imagebf3343.JPG@c9d2fbd2.4db10e0d] <http://www.rtconline.com>
Tel: 985.536.1214 Fax: 985.536.0300 Email: kvicknair@reservetele.com Web: www.rtconline.com
Reserve Telecommunications 100 RTC Dr Reserve, LA 70084
Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Kody Vicknair immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Kody Vicknair therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission.
On 9/9/17, 12:06 PM, "NANOG on behalf of Kody Vicknair" <nanog-bounces@nanog.org on behalf of kvicknair@reservetele.com> wrote:
All,
I’ve been doing some reading in preparation of IPv6 deployment and figuring out how we will break up our /32. I think I’m on the right track in thinking that each customer will be allocated a /48 to do whatever they wish with it.
Yes.
I’ve read recent BCOP drafts that have been approved by the IETF: https://www.ripe.net/publications/docs/ripe-554
BCOP isn’t an IETF BCP. But that’s a really minor detail; BCOPs much better operator input than most IETF activities (IMHO, as an active IETF participant).
It looks like the smallest subnet that should ever be assigned is a /64 on a particular link.
Some questions that come to mind with IPv6:
In regards to Point to point links my thinking is this: Assign a unique /64 to each point to point link with these addresses being Globally routable. This seems to be what our IX providers do when assigning us an IPv6 address. Am I correct in this train of thought? Why/Why not?
Yes, the general guidance is to reserve a /64 for the link and configure a very small subnet (like /127) on the interfaces, to avoid a ping-pong attack.
In regards to core loopback addressing my initial thoughts are as follows: Assign a single /64 encompassing all /128’s planned for loopback addressing schemes. Should I be using Unique Local addressing for loopbacks instead of going with a Globally routeable addressing scheme? Should each interface IP configuration have a /64 or a /128?
You can use ULAs for this; I know of a moderately sized network that does. I think most people still use GUA. You’re not wrong either way, though I know some people get emotional about ULA.
Also when talking about CPE mgmt addresses what do you think is a practical way of going about assigning “Private” addressing schemes for cpe management purposes.
Reserve another block from your /32 and route it separately. As somebody else said, if you find you’re running out of address space in IPv6, there’s no shame in requesting more than a /32.
I’m sure some of these questions will be answered when I dive deeper into how OSPFv6 works as well as BGP in regards to IPv6.
Maybe, but don’t panic. It’s not significantly harder in IPv6 than in IPv4.
Are any of you currently running IPv6 and wished you had done something differently during the planning phase that may have prevented headaches down the road?
I always tell people: you’re going to rewrite your address plan three times. Do what you can with it, then start deploying through the network. You’ll see what changes you need to make once you know how your network is unique. I wish I’d pushed harder for /48s for customers from the beginning, even though we would’ve needed more address space. I wish I’d started sooner, but more than that I wish my vendors had started sooner, especially CPE vendors. I wish I had just replaced broken equipment rather than working around it. I wish I had had better monitoring of both IPv4 and IPv6 specific systems, so I could tell when one address family failed. I wish I had been able to plan my transition technology earlier, so I could move from dual-stack to IPv6. Lee
Kody Vicknair Network Engineer
[cid:imagebf3343.JPG@c9d2fbd2.4db10e0d] <http://www.rtconline.com>
Tel: 985.536.1214 Fax: 985.536.0300 Email: kvicknair@reservetele.com Web: www.rtconline.com
Reserve Telecommunications 100 RTC Dr Reserve, LA 70084
Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Kody Vicknair immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Kody Vicknair therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission.
On 12 September 2017 at 01:08, Lee Howard <lee@asgard.org> wrote:
Are any of you currently running IPv6 and wished you had done something differently during the planning phase that may have prevented headaches down the road?
I always tell people: you’re going to rewrite your address plan three times. Do what you can with it, then start deploying through the network. You’ll see what changes you need to make once you know how your network is unique.
Also write your iACL/edge-filter before you deploy your IPv6. If you can't write concise, almost static IPv6 iACL, your numbering plan requires work. -- ++ytti
participants (12)
-
Baldur Norddahl -
Enno Rey -
Job Snijders -
Kody Vicknair -
Lee Howard -
Masood Ahmad Shah -
Nick Hilliard -
Nikolay Shopik -
Owen DeLong -
Saku Ytti -
sthaug＠nethelp.no -
Thomas Bellman