diff options
Diffstat (limited to 'writeups/ipv6/rfc4191')
| -rw-r--r-- | writeups/ipv6/rfc4191/image-1.png | bin | 0 -> 33373 bytes | |||
| -rw-r--r-- | writeups/ipv6/rfc4191/image-2.png | bin | 0 -> 172452 bytes | |||
| -rw-r--r-- | writeups/ipv6/rfc4191/image-3.png | bin | 0 -> 47412 bytes | |||
| -rw-r--r-- | writeups/ipv6/rfc4191/image.png | bin | 0 -> 83754 bytes | |||
| -rw-r--r-- | writeups/ipv6/rfc4191/rfc4191.ko.md | 125 | ||||
| -rw-r--r-- | writeups/ipv6/rfc4191/rfc4191.md | 134 | ||||
| -rw-r--r-- | writeups/ipv6/rfc4191/severed_link.mp4 | bin | 0 -> 877815 bytes | |||
| -rw-r--r-- | writeups/ipv6/rfc4191/severed_link.webp | bin | 0 -> 2396278 bytes |
8 files changed, 259 insertions, 0 deletions
diff --git a/writeups/ipv6/rfc4191/image-1.png b/writeups/ipv6/rfc4191/image-1.png Binary files differnew file mode 100644 index 0000000..08674d4 --- /dev/null +++ b/writeups/ipv6/rfc4191/image-1.png diff --git a/writeups/ipv6/rfc4191/image-2.png b/writeups/ipv6/rfc4191/image-2.png Binary files differnew file mode 100644 index 0000000..69f028e --- /dev/null +++ b/writeups/ipv6/rfc4191/image-2.png diff --git a/writeups/ipv6/rfc4191/image-3.png b/writeups/ipv6/rfc4191/image-3.png Binary files differnew file mode 100644 index 0000000..ec629e0 --- /dev/null +++ b/writeups/ipv6/rfc4191/image-3.png diff --git a/writeups/ipv6/rfc4191/image.png b/writeups/ipv6/rfc4191/image.png Binary files differnew file mode 100644 index 0000000..2b661c2 --- /dev/null +++ b/writeups/ipv6/rfc4191/image.png diff --git a/writeups/ipv6/rfc4191/rfc4191.ko.md b/writeups/ipv6/rfc4191/rfc4191.ko.md new file mode 100644 index 0000000..2558cca --- /dev/null +++ b/writeups/ipv6/rfc4191/rfc4191.ko.md @@ -0,0 +1,125 @@ +# 무중단 네트워크 서비스의 첫걸음: RFC 4191 +[RFC 4191](https://datatracker.ietf.org/doc/html/rfc4191)에 라우터 정보 +옵션(RIO)이 추가됨. 이는 [RFC +3442](https://serverfault.com/questions/640565/how-can-i-configure-my-dhcp-server-to-distribute-ip-routes)와 +같이 LAN 내의 노드에 라우트를 전달하는 방법을 제공함. 단순한 DHCPv4와 달리, RA는 +트래픽을 실제로 라우팅하는 라우터에서 돌아감. 이는 여러 가지 옵션을 탐색할 수 +있는 가능성을 제공한다: + +1. BGP의 ECMP 및 MED와 비슷한 방식의 부하 분산 +1. 다중 프리픽스 경로: 다중 transparent VPN 게이트웨이, 사설망 +1. fault tolerance: 네트워크의 단일 장애점(single point of failure)를 제거하기 + 위해 옵션의 lifetime 속성 사용 가능 + +## 운영체제 지원 +RFC 4191을 지원하는 운영체제는 RA 메시지에서 RIO를 받아 라우팅 테이블에 해당 +프리픽스를 추가한다. + +| OS | Support | From | Note | +| - | - | - | - | +| 윈도 | YES | ? | [Windows Server 2012 문서](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/jj574227(v=ws.11))에 처음 언급됨 | +| 리눅스 | MAYBE | [v2.6.17-rc1](https://github.com/torvalds/linux/blame/4236f913808cebef1b9e078726a4e5d56064f7ad/net/ipv6/ndisc.c#L258) | `CONFIG_IPV6_ROUTE_INFO` 옵션 기본적으로 꺼져있음. 대부분의 배포판이 옵션을 켜 빌드함 | +| 안드로이드 | YES | ? | 리눅스 지원이 안드로이드가 출시되기 전부터 있었음 | +| XNU(IOS, macos) | YES | [xnu-7195.50.7.100.1](https://github.com/apple-oss-distributions/xnu/blame/8d741a5de7ff4191bf97d57b9f54c2f6d4a15585/bsd/netinet6/nd6_rtr.c#L490) | https://theapplewiki.com/wiki/Kernel#Versions | +| FreeBSD | [NO](https://github.com/freebsd/freebsd-src/blob/47ca5d103f229b090899379ce449af5e89faf627/sys/netinet6/nd6.c#L507) | - | 라우터 탐색 프로세스가 "rtsold" 유저스페이스 프로그램에 구현됨 | +| OpenBSD | [NO](https://github.com/openbsd/src/blob/36a0e83f909d48cbb69156be916b6356c14b9ae5/sbin/slaacd/engine.c#L1555) | - | 라우터 탐색 프로세스가 "slaacd" 유저스페이스 프로그램에 구현됨 | + +## 실전 RFC 4191 +<img src="../radvd/drawing-a.svg" style="background: grey;"> + +사무실 건물 1과 2 사이에 사설 L2 망이 있다 치자. 당연히 각 건물에는 인터넷을 +위한 default 라우터가 있음. 두 건물에 존재하는 노드 수가 2048개(이더넷 스위치의 +한계)도 되지 않는다면, 두 건물을 같은 L2 세그먼트로 운영할 수 있으므로 사설망을 +위해 라우터는 불필요하다. 하지만 노드 수가 2048개 이상이면? + +그럴 경우 네트워크를 분리해야 함. 네트워크를 분리하려면 라우터가 필요함. 일을 더 +키우는 격으로 보이지만, 나중을 위해 충분히 가치 있는 일임. + +사설망 라우터의 `radvd.conf` 파일은 다음과 같이 설정 가능. + +```conf +# 1번 건물 네트워크 인터페이스 +interface eth0 { + AdvSendAdvert On; + # 전 노드에 이 라우터를 게이트웨이로 쓰지 말라고 알림 + AdvDefaultLifetime 0; + MinRtrAdvInterval 30; + MaxRtrAdvInterval 120; + + route 2001:db8:0ff1ce:2::/54 { + # 1분 안에 새로운 RA 메시지가 수신되지 않으면 + # 노드는 이 프리픽스를 테이블에서 제거함(expire) + AdvRouteLifetime 60; + }; +}; + +# 사설망 인터페이스 +interface eth1 { + AdvSendAdvert On; + # 상대 라우터에게 이 라우터를 게이트웨이로 쓰지 말라고 알림 + AdvDefaultLifetime 0; + MinRtrAdvInterval 30; + MaxRtrAdvInterval 120; + + route 2001:db8:0ff1ce:1::/54 { + # 상대 라우터가 1분 이내에 새로운 RA 메시지를 받지 못하면, + # 상대 라우터는 트래픽을 게이트웨이 라우터로 돌리기 시작함 (redirect) + AdvRouteLifetime 60; + }; +}; +``` + +라우터가 전송하는 RA 메시지는 첫번째 이미지와 같이 보일 것임. 게이트웨이 +라우터와 사설망 라우터가 동시에 RA 메시지를 송출하는 경우에는, 각 노드에는 +두번째 이미지와 같이 라우팅 테이블이 형성될 것임. + + + + +### 건물 사이 사설망 장애 + + +사설망 중간에 중계기가 브리지가 없어서 라우터에 바로 링크 다운 상황(NO +CARRIER)이 감지되면, 두 라우터는 즉시 트래픽을 게이트웨이로 우회하기 +시작함([ICMPv6 +redirect](https://datatracker.ietf.org/doc/html/rfc4861#section-4.5)). + +어찌되었건 두 라우터가 RA 메시지나 ND를 할 수 없는 상황이면 라우터는 각자 +프리픽스를 1분 뒤 만료시켜 삭제할 것임. 삭제되면 트래픽은 게이트웨이로 우회되기 +시작함. + +네트워크 사용자(그리고 네트워크 관리자 마저도)는 별다른 이상징후를 포착하기 힘들 +것임. 하지만 ICMP redirect 프로세스가 효율적이지 않음. 그리고 내부 트래픽이 +인터넷을 타기 시작하면서 인터넷 망에 부하가 걸리기 시작하고, 내부 정보가 +유출되는 상황이 연출될 수 있음. 업무에 사용하는 애플리케이션은 내부 트래픽을 +특수하게 처리하지 않으면 그리 문제가 없지만, 만일의 정보 유출을 대비해서 +게이트웨이 라우터에도 내부 프리픽스 트래픽을 VPN으로 암호화하는 것을 추천함. + +### 사설망 라우터 장애 +최대 1분 동안 두 건물이 서로 통신을 하지 못할 것임. 1분이 지나 라우팅 정보가 +만료되면 노드들이 내부 트래픽을 게이트웨이로 전송하기 시작할 것임. + +다른 라우터가 멀쩡한 건물의 사용자도 똑같이 1분 동안 장애를 겪을 것임. 그러나, +라우터의 프리픽스 정보가 만료되고 나면 라우터는 게이트웨이로 트래픽을 우회하기 +시작할 것임. 이는 효율적이지 않음. 이를 막기 위해서 라우터를 수리하기 전까지는 +사설망을 바로 건물 L2에다 연결하거나(bypass) 사설 라우터를 내려서 내부 트래픽도 +인터넷을 타도록 할 수 있음. + +### 인터넷 장애 +... 뭐, 인터넷이 일단 안되겠지만, 사무실 사람들은 서로 각자 다른 건물에 있는 +자원을 계속 사용할 수 있음! + +### 전부 다 이중화! +사설망 라우터를 여러개 둘 수 있음. 각자 RA 메시지를 송출할 수 있고, 그렇게 되면 +노드에 라우팅 테이블이 다음과 같이 형성됨. 이건 사설망 라우터 뿐만 아니라 +게이트웨이에도 적용할 수 있음. + + + +테이블에 목적지가 여러개 잡혀 있으면 노드는 그 중 하나를 택해서, 하나만 쓰도록 +되어있음. 어떤 것이 선택되는 지는 거의 랜덤이므로 어느 정도의 로드벨런싱이 +가능함. + +이 구성은 크게 늘릴 수 있음. 그러다보면 IBGP를 사용해야 하는 지경까지 가고, +완벽한 무정전 서비스를 하려면 업무에 쓰는 모든 서비스를 직접 현장에서 호스팅해야 +하긴 함. 거기까지는 무리일 듯. diff --git a/writeups/ipv6/rfc4191/rfc4191.md b/writeups/ipv6/rfc4191/rfc4191.md new file mode 100644 index 0000000..8f4d73f --- /dev/null +++ b/writeups/ipv6/rfc4191/rfc4191.md @@ -0,0 +1,134 @@ +# Towards Zero Downtime: RFC 4191 +[RFC 4191](https://datatracker.ietf.org/doc/html/rfc4191) defines the router +information option(RIO). It's effectively a way to push routes to the nodes in +the LAN similar to [RFC +3442](https://serverfault.com/questions/640565/how-can-i-configure-my-dhcp-server-to-distribute-ip-routes). +Unlike monolithic and authoritative DHCPv4, RA is done by the actual routers +that are responsible for routing traffic. This gives us many options to explore: + +1. Load balancing: analogous to ECMP and MED in BGP +1. Multiple prefix exit routes: transparent multiple VPN gateways, private links +1. Fault tolerance: use of lifetime attributes to eliminate single point of + failure in the network + +## OS Support +An operating system that supports RFC 4191 should accept the RIOs in RA messages +and add the prefixes in the routing table. + +| OS | Support | From | Note | +| - | - | - | - | +| Windows | YES | ? | First mention in [Windows Server 2012 doc](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/jj574227(v=ws.11)) | +| Linux | MAYBE | [v2.6.17-rc1](https://github.com/torvalds/linux/blame/4236f913808cebef1b9e078726a4e5d56064f7ad/net/ipv6/ndisc.c#L258) | `CONFIG_IPV6_ROUTE_INFO` disabled by default, but most distros enable it | +| Android | YES | ? | Linux support predates Android, so it has been enabled for a long time | +| XNU(IOS, macos) | YES | [xnu-7195.50.7.100.1](https://github.com/apple-oss-distributions/xnu/blame/8d741a5de7ff4191bf97d57b9f54c2f6d4a15585/bsd/netinet6/nd6_rtr.c#L490) | https://theapplewiki.com/wiki/Kernel#Versions | +| FreeBSD | [NO](https://github.com/freebsd/freebsd-src/blob/47ca5d103f229b090899379ce449af5e89faf627/sys/netinet6/nd6.c#L507) | - | Router discovery implemented in userspace "rtsold" | +| OpenBSD | [NO](https://github.com/openbsd/src/blob/36a0e83f909d48cbb69156be916b6356c14b9ae5/sbin/slaacd/engine.c#L1555) | - | Router discovery implemented in userspace "slaacd" | + +## RFC 4191 in Action +<img src="../radvd/drawing-a.svg" style="background: grey;"> + +Imagine a set up where there are a private L2 link between the office building +one and two. Obviously, default routers should run on each building for internet +connection. If the number of nodes in both buildings are less than 2048(safe +limit for ethernet switches), the routers for the private link wouldn't be +necessary because the buildings can be put in the same L2 segment. What if there +are more than 2048 nodes? + +In that case, the network will need to be segmented. In order to segment the +networks, additional routers need to be introduced. Yes, this can lead to more +work, more things to maintain. But it sure will be worth it. + +The `radvd.conf` on the private link router will look something like this. + +```conf +# iface to building #1 segment +interface eth0 { + AdvSendAdvert On; + # this tells the nodes that this router is NOT a default router + AdvDefaultLifetime 0; + MinRtrAdvInterval 30; + MaxRtrAdvInterval 120; + + route 2001:db8:0ff1ce:2::/54 { + # if no further RA message is received within 1 minute, + # the nodes will expire this prefix + AdvRouteLifetime 60; + }; +}; + +# iface to the private link +interface eth1 { + AdvSendAdvert On; + # this tells the other router that this router is NOT a default router + AdvDefaultLifetime 0; + MinRtrAdvInterval 30; + MaxRtrAdvInterval 120; + + route 2001:db8:0ff1ce:1::/54 { + # if no further RA message is received within 1 minute by the other + # router, the other router will start redirecting traffic to the default + # router + AdvRouteLifetime 60; + }; +}; +``` + +The RA message will look someting like the first image. When both default and +private link router are sending their RA messages, the routing table on the +nodes will look similar to the second image. + + + + +### Failure of private link between the buildings + + +If there's no mac bridges(repeaters and such) and the link down(NO CARRIER) +condition is detected directly by the routers, the routers will immediately +start [redirecting](https://datatracker.ietf.org/doc/html/rfc4861#section-4.5) +traffic to the default routers. + +In any other case, in which routers are not able to exchange RA messages or do +neighbor discovery, the prefix in the table of respective routers will expire in +1 minute after the incident. Then the routers will start redirecting the +traffic. + +The network users(and even the network admin themselves) won't be able to notice +anything out of ordinary. However, ICMPv6 redirect is not an efficient process. +As the internal traffic starts following out to the internet and back, the +failover state will put strain on the default routers and the internet backbone +routers. The applications must not make any assumptions about the network and +treat traffic within the organisation any different. Information leak can still +happen so it could be a good measure to have the VPN for the internal traffic on +the default routers as well. + +### Failure of the private link routers +The nodes in the building won't be able to reach the nodes in the other building +for maximum of 1 minute. After the route expires, the nodes will start using the +default router to reach the other nodes. + +The nodes in the other building will experience the same downtime. However, when +the prefix expires in the router expires, it will start doing ICMPv6 redirect, +which is not efficient. To avoid this, until the problem is resolved, the L2 +link can be bypassed to put the private link on the building segment or the +other router can be taken down so that the internal traffic is routed to the +internet. + +### Internet Service Disruption +Well, there will be no internet :(. But people will be able to use resources on +the other building! + +### Multiple of Everything! +There can be multiple routers facing the private link. They can all send RA +messages independent of each other. This also applies to the default routers as +well. The routing table on the nodes will look similar to this: + + + +Note that a node will choose one of multiple routers for the destination. Which +one it chooses is basically random, so some level of load balancing can be +achieved. + +This set up can be scaled up to many buildings and routes. It'll eventually get +to a point where IBGP is better suited for the purpose, and also, the services +would have to be self-hosted on premise. That's what I call a "long shot". diff --git a/writeups/ipv6/rfc4191/severed_link.mp4 b/writeups/ipv6/rfc4191/severed_link.mp4 Binary files differnew file mode 100644 index 0000000..e44f191 --- /dev/null +++ b/writeups/ipv6/rfc4191/severed_link.mp4 diff --git a/writeups/ipv6/rfc4191/severed_link.webp b/writeups/ipv6/rfc4191/severed_link.webp Binary files differnew file mode 100644 index 0000000..11cbc31 --- /dev/null +++ b/writeups/ipv6/rfc4191/severed_link.webp |
