Es la vida~

1. 개요

IETF에서 표준화되어 있는 mobile IPv6는 단말에 mobile IPv6 스택을 올려서 이동성을 지원하는 기술이다. 하지만 이 프로토콜을 사용하기 위해서는 이동성을 요구하는 단말이 mobile IPv6 기능을 지원할 수 있도록 설계되어야 하며, 각종 메시지 교환과 같이 복잡한 절차 때문에 무선 링크 자원의 낭비가 심하고 장비 자체에 걸리는 부하나 전력 소모량이 크다는 단점을 가지고 있어서 시장에서 활성화되지 못하고 있다. 이와 같은 단점을 해결하기 위해 네트워크 기반의 이동성 관리 기법이 소개되었다. 네트워크 기반의 이동성 관리 기법이란 단말에 특정한 mobile IPv6와 같은 기능이 구현되지 않더라도 기존의 연결이 지속적으로 유지될 수 있도록 액세스 망에서 관리를 해주는 것을 말한다. IETF에서는 PMIPv6(proxy mobile IPv6)라는 네트워크 기반의 이동성 관리 기법을 [1]이라는 표준문서를 정의하였다. 본 문서에서는 PMIPv6 구성 요소 중 MAG(mobile access gateway)의 동작 절차에 대해 설명한다.

2. MAG 동작 절차

PMIPv6 프로토콜에서는 새로운 네트워크 엔티티로 LMA(local mobility anchor) 외 MAG를 정의한다. MAG는 액세스 링크로부터 MN의 이동을 감지하며 LMA로 PBU(proxy binding update) 메시지를 통해 이러한 정보를 전송하게 된다. 여기서 MAG는 MN을 대신하여 MN의 이동성 절차를 수행하게 된다. MAG는 보통 액세스 라우터에 구현되는 것이 일반적이지만 이를 다른 여러 네트워크 엔티티로 나눠서 구현하는 것이 가능하다. 이에 대한 세부적인 구현 사항은 [1]에 명시되지 않았고 다음과 같은 MAG에서의 주요 기능을 명시하고 있다.

• MAG는 액세스 링크로부터 MN의 이동을 감지하며 MN의 이동성 절차를 LMA와 수행한다.

• LMA에서 MN의 prefix 정보를 담은 RA(router advertisement) 메시지를 전송함으로써 MN의 홈링크 주소를 생성한다. 이 때 prefix는 RFC 4861에 명시된 prefix information option을 통해 전송된다.

• MN이 홈네트워크 prefix로부터 하나 혹은 그 이상의 주소 생성하는 것을 가능하게 한다.

2.1. 기존 binding update list의 확장

모든 MAG는 BUL(binding update list)를 유지해야만 한다. BUL의 각 항목은 MN의 LMA와 binding을 맺은 이동성 정보를 나타낸다. [2]의 11.1에 나와 있는 BUL과 같은 구조를 갖으며 추가적으로 다음과 같은 필드를 가지고 있다.

• MN-ID

Attach한 MN의 식별자로 MN이 액세스 링크로 attach 하는 동안에 획득하게 된다.

• Link-layer identifier

MN이 접속한 인터페이스의 링크 계층 식별자로 MN에서 전송한 RS 메시지를 통해 생성되거나 MN이 액세스 네트워크로 attach할 때 생성될 수 있다. 이는 주로 MN에 의해 전송되는 링크 계층 식별자이다. 만약 이 식별자가 사용되지 않는다면, 이 변수 길이 필드는 2 octets으로 세팅되어야만 하고 모두 0으로 초기화 되어야 한다.

• IPv6 home network prefixes

MN이 접속한 인터페이스에 할당된 IPv6 홈 네트워크 프리픽스들의 리스트를 말한다. 홈 네트워크 프리픽스들은 정적으로 MN의 policy profile에 따라 할당되거나 LMA에 의해 동적으로 할당된다. 각 프리픽스 항목들은 그에 상응하는 프리픽스 길이를 포함한다.

• MAG의 link local address

MN과 공유하고 있는 액세스 링크 상의 MAG 링크 로컬 주소를 말한다.

• LMA의 IPv6 address

MN이 attach하고 있는 LMA의 IPv6 주소를 말하며 MN의 policy profile이나 다른 방법에 의해 생성될 수 있다.

• MN과 MAG 간의 점대점 링크에서의 인터페이스 식별자(if-id)

If-id는 MAG 내부에 존재하며 PMIPv6 터널을 MN이 attach한 액세스 링크와 연결하는데 사용된다.

• LMA와 MAG 간 양방향 터널의 터널 인터페이스 식별자(tunnel-if-id)

Tunnel-if-id는 MAG 내부에 존재하며 터널이 생성되는 동안에 획득할 수 있다.

2.2. MN의 policy profile

MN의 policy profile은 MN의 이동성 관리를 위해 네트워크 엔티티에 필요로 하는 파라미터를 가지고 있다. 이러한 policy profile은 로컬 혹은 원격 policy store에 저장된다. MAG나 LMA는 MN의 policy profile을 가질 수 있어야 하며 이러한 policy profile은 핸드오버 기간동안 serving MAG로 전송될 수 있다. 또한, serving MAG는 이러한 profile을 경우에 따라 생성할 수도 있다. 이에 대한 자세한 사항은 [1]에 나와있지 않으며 MAG는 MN이 가지고 있는 policy profile에 접근이 가능해야 한다. Policy profile에 있어 필수적으로 존재해야하는 필드는 다음과 같다.

• MN-ID

• LMAA(LMA IPv6 address)

그리고 다음의 필드들은 필수적인 사항은 아니고 옵션으로서 가능한 필드들이다.

• MN이 접속한 인터페이스에 할당된 MN의 IPv6 홈네트워크 프리픽스

이 프리픽스들은 인터페이스 별로 유지되어야 하며 MN의 각 인터페이스를 위한 여러 항목들이 있을 수 있다.

• MN의 IPv6 홈네트워크 프리픽스 lifetime

이 lifetime은 링크 상에 모든 프리픽스들에 있어 똑같은 값을 가진다. 또한 lifetime은 MN의 여러 이동성 세션에 있어 같은 값을 가질 수 있다.

• PMIPv6 도메인 내에서 MN을 위한 주소 할당 방식은 stateful, stateless, 그리고 두 가지 방식 모두 사용하는 방식이 가능하다.

2.3. 지원가능한 액세스 링크 타입

PMIPv6 프로토콜은 점대점 액세스 링크 타입만을 지원하며 MN과 MAG와 같이 액세스 링크 상에서 오직 두 개의 노드만이 존재한다고 가정한다. 또한, 액세스 링크 내에서 멀티캐스트 방식의 트래픽 전송이 가능하다. 또한 PMIPv6 프로토콜은 링크가 MN과 MAG 간에 모든 트래픽을 위한 점대점 방식의 전송이 가능하다고 가정하는 한 다른 링크 타입에서도 사용이 가능하다. 이 때 다른 링크 타입이 어떤 부분인지는 스펙에 명시되어 있지 않다. 그리고 링크에 attach한 MN을 확인할 수 있어야 하는데 이와 관련된 사항은 [1]의 6.6 섹션에 나와 있으니 참고하길 바란다. 마지막으로 PMIPv6 프로토콜이 링크에 attach 및 detach와 관련된 링크 계층 정보 전송 없이 동작할 수 있는 반면, 이러한 링크 계층 정보 전송은 네트워크나 MN 측면에서 성능향상을 가져올 수 있다.

2.4. 지원하는 주소 할당 모드

PMIPv6 도메인 내에서 MN은 하나 혹은 그 이상의 주소를 인터페이스에 할당할 수 있다. 이 때 stateless, stateful 혹은 수동으로 주소를 할당할 수 있다. 액세스 링크 상에 보내지는 RA 메시지는 MN을 위한 액세스 링크 상에 허용된 주소 할당 방법을 명시하게 된다. 그러나 주소할당과 관련된 플래그는 MN과 일치할 것이다. 일반적으로 이러한 주소할당 세팅은 네트워크 기반의 policy 혹은 MN 기반의 policy에 따라 다를 수 있다.

Stateless 주소 할당 방식을 액세스 링크 상에서 지원한다면, stateless 주소 할당방식이 명시된 RFC 4862 혹은 RFC 4941 표준의 메커니즘에 따라 MN은 하나 혹은 그 이상의 IPv6 주소를 생성할 수 있다. Stateful 주소 할당 방식이 링크 상에서 지원한다면, MN은 PMIPv6 도메인 내에 위치한 DHCP 서버로부터 주소를 생성할 수 있으며 이러한 메커니즘은 RFC 3315 표준에 따른다. 자세한 사항은 [1]의 6.11에 명시되어 있으니 참고하길 바란다.

추가적으로 MN과 MAG 사이의 링크에 특화된 또 다른 주소할당 메커니즘이 MN의 주소를 설정하는데 사용될 수 있다. 이러한 스펙은 표준 IPv6 주소 할당 메커니즘의 어떠한 부분도 수정 및 변경하지 않는다.

2.5. 액세스 인증 및 MN ID

MN이 MAG가 연결된 액세스 링크 상에 attach할 때, 링크 상의 액세스 보안 프로토콜들은 네트워크 기반의 이동성 관리 서비스가 MN의 사용자 인증 및 권한 부여가 이루어 진후 제공되어야 한다는 것을 보장해야만 한다. 이에 대한 자세한 사항은 표준 문서에 명시되어 있지 않으며 이러한 스펙은 PMIPv6 프로토콜이 동작하기 전에 MN과 MAG 사이에 이미 제공되고 있어야 한다는 가정 하에 수행되어야만 한다.

2.6. MN ID 획득

PMIPv6 도메인 내에서 모든 네트워크 엔티티들은 MN ID를 이용하여 MN을 식별할 수 있어야만 한다. MN ID는 유일하며 변경되지 않는 것이 특징이다. PMIPv6 도메인 내에서 이동성 엔티티들은 시그널링 절차에 있어 MN ID를 이용할 수 있어야만 하고 이 식별자를 통해 해당 MN을 식별할 수 있어야 한다. 다음은 MN ID와 관련된 고려 사항들을 나타낸 것이다.

• MN ID는 액세스 인증의 일부분 혹은 네트워크 attach 이벤트에 의해 얻어질 수 있다. MN을 식별하기 위한 인증 절차로 사용자 식별자(user identifier)를 사용하는 경우, 이 사용자 식별자 또한 MN ID로 사용될 수 있다. 그러나 사용자 식별자는 만약 사용자 동일한 PMIPv6 도메인 내에서 동작 중인 하나 이상의 MN으로부터 사용되고 있다면 이용되지 말아야 한다.

• 일부 경우에 있어 액세스 인증으로부터 획득한 식별자는 임시적인 식별자일 수 있다. 이러한 임시적인 식별자는 재인증과는 다른 개념이지만 MAG는 이러한 임시적인 식별자를 이용할 수 있어야만 하고 policy store로부터 MN ID를 획득할 수 있어야만 한다. 예를 들어 AAA 기반의 시스템에서 RADIUS(remote authentication dial-in user service) 속성 및 RFC 4372에 명시된 chargeable-user-identifier가 여러 MN을 식별하는 데 이용되는 것이 아닌 하나의 MN을 식별하는 데 이용되는 한 사용될 수 있다.

• 일부 경우 혹은 사적인 이유로 policy store가 MAG로 전송하는 MN ID는 MN의 진정한 식별자는 아니다. 그러나 MAG는 LMA와의 시그널링 메시지 절차에 MN ID를 이용할 수 있어야만 한다.

• MAG는 MN ID에 의해 MN을 식별할 수 있어야만 하며 MN과 연결된 점대점 링크에 이러한 식별자를 연관시킬 수 있어야만 한다.

2.7. 홈 네트워크 emulation

MAG의 주요 특징 중 하나는 액세스 링크 상에서 MN의 홈네트워크인 것처럼 가장한다는 것이다. 즉, PMIPv6 도메인 내에서 attachment point가 변한다 할지라도 MN은 3 계층과 관련된 어떠한 변화도 감지할 수 없다는 것이다. 이는 PMIPv6에서 MN이 이동성 절차에 관여하지 않기 때문이다. MAG는 액세스 링크 상에서 MN의 홈링크인 것처럼 가장하기 위해 MN의 홈네트워크 prefix를 광고할 수 있는 RA 메시지를 전송할 수 있어야만 한다. 일반적으로 이러한 세팅은 도메인 기반 혹은 MN 기반 policy에 따른다.

일반적으로 MAG는 MN의 홈네트워크 프리픽스를 LMA로부터 수신한 PBA 메시지를 통해 알게 되거나 MN의 policy profile로부터 얻게 된다. 그러나 MAG는 MN의 LMA와 binding registration 절차가 성공적으로 완료된 후에 RA 메시지를 보내야만 한다.

RA 메시지를 통해 홈네트워크 프리픽스를 광고하는 MAG는 광고한 프리픽스의 lifetime 값을 설정하게 된다.

2.8. 링크 로컬 주소, 글로벌 주소의 유일성

PMIPv6 도메인에서 MN은 다른 MAG로 핸드오버하게 될 때 L3 attachment의 변화가 아닌 홈 네트워크 상의 변화를 감지하게 된다. MN이 새로운 링크로 attach하게 될 때마다 인터페이스의 변동과 관련된 이러한 이벤트는 MN이 링크 로컬 주소와 글로벌 주소에 있어 DAD(duplicate address detection) 과정을 수행하게 한다. 주소가 충돌나는 문제는 MN의 글로벌 주소와 관련이 없다. 할당된 홈네트워크 프리픽스는 MN만이 사용하도록 할당되었기 때문에 어떠한 다른 노드는 이 프리픽스로부터 주소를 공유할 수 없으며 그럼으로 인해 MN의 글로벌 주소에 대한 유일성은 액세스 링크상에 보장된다. 반면 주소 충돌과 관련된 이슈는 MN의 링크 로컬 주소와 관련이 있다. 이는 MAG와 MN은 FE80:/64의 링크 로컬 프리픽스로부터 형성된 링크 로컬 주소를 가지기 때문이다.

PMIPv6에서는 MAG가 형성한 MN과 점대점 링크로 형성된 링크 로컬 주소는 LMA에 의해 생성되어야만 하며 이는 MN의 BCE(binding cache entry)에 저장된다. 링크 로컬 주소는 MN이 핸드오버 하는 동안 변하지 않게 되며 MN이 핸드오버할 때마다 PMIPv6의 메시지를 통해 serving MAG으로 제공된다. LMA가 링크 로컬 주소를 생성하는 방법에 대해서는 본 스펙에서 기술하지 않고 있다.

MN과 공유하고 있는 MAG 상의 액세스 링크는 MN이 링크 로컬 주소의 DAD 과정을 완료하기 전에 MAG가 LMA에 의해 제공된 링크로컬 주소를 가지고 있어야 하는 등의 준비가 되어 있어야 한다. 이것은 MN이 DAD 과정을 완료하기 전에 MAG에 의해 PMIPv6 시그널링 절차가 성공적으로 완료할 것을 요구한다. 또한 이는 링크 계층 attachment가 PMIPv6 시그널링이 완료되고 나서야 완료되는 것을 보장함으로써 이루어진다. 또한 다른 방법으로 네트워크와 LMA capacity와 시그널링 재전송 타이머들은 DAD 과정과 관련된 default 대기 시간 동안 시그널링이 완료될 것 같다는 점에서 필요할 수 있다.

실제로 구현할 때는 PMIPv6 도메인 내 모든 액세스 링크에 있어 링크 로컬 주소를 PMIPv6 절차를 통해 LMA로부터 MAG로 전송할 필요 없이 고정된 링크 로컬 주소를 생성하게 하는 방법이 있을 수 있다. 이를 위한 설정 변수인 FixedMAGLinkLocalAddressOnAllAccessLinks 변수는 PMIPv6 도메인에서 가능한 모드를 결정짓는다.

2.9. 시그널링 고려사항

2.9.1. Binding 등록

• MN attachment, 초기 binding 등록

1. 액세스 링크 상에서 새로운 MN을 감지한 후에 MAG는 MN을 확인하게 되고 MN ID를 얻는다. 만약 네트워크 기반의 이동성 관리 서비스가 MN에 제공될 필요가 있다고 판단되면 LMA로 PBU 메시지를 전송해야 한다.

2. PBU 메시지는 MN을 확인하기 위한 MN ID를 가지고 있는 MN ID option을 포함해야만 한다.

3. Home network prefix 옵션은 PBU 메시지에 나타나야만 한다. 만약 MAG가 MN의 홈네트워크 프리픽스를 policy store 혹은 다른 수단을 통해 알게 되면 MAG는 LMA가 home network prefix 옵션을 포함함으로써 특정 프리픽스를 할당하도록 요청할 수도 있다. MAG는 또한 LMA가 프리픽스 할당을 하도록 프리픽스 값이 모두 0으로 채워진 단 하나의 home network prefix 옵션을 포함할 수도 있다. 그러나 모두 0으로 채워진 home network prefix 옵션을 포함할 때는 단 하나의 home network prefix 옵션만을 포함해야 한다.

4. Handoff indication 옵션은 PBU 메시지에 나타나야만 한다. 이 옵션 내 handoff indicator 필드는 handoff hint가 가리키고 있는 값을 설정해야만 한다.

5. MAG는 handoff indicator 필드의 값을 선택하는 데 있어 다음과 같은 사항들을 고려해야 한다.

6. MN의 이동성 세션 정보에서 timestamp option과 sequence number는 반드시 명시되어 있어야 한다. 이는 설정 플래그인 TimestampBasedApproachInUse의 값에 따라 결정될 수 있다. Timestamp option이 메시지에 추가될 때 MAG는 sequence number 필드를 설정해야만 한다. LMA는 timestamp option이 request 메시지에 있을 때 이 필드를 무시하지만 PBA 메시지에 같은 값을 반환할 것이다. 이는 request 메시지에 대한 응답을 보낼 때 유용할 수 있다.

7. MN이 현재 attach한 인터페이스의 link layer identifier를 가지고 있는 MN link-layer identifier option은 PBA 메시지에 포함되어야 한다. 만약 현재 attach한 인터페이스의 link-layer identifier가 알려지지 않았거나 identifier의 값이 0일 경우 이러한 option은 포함시키지 말아야 한다.

8. Access technology type은 PBA 메시지에 나타나야 한다. Option 내에 access technology type 필드는 MN이 현재 MAG에 attach한 access technology의 type으로 설정되어야 한다.

9. 만약 FixedMAGLinkLocalAddressOnAllAccessLinks 설정변수의 값만이 모두 0으로 설정되어 있다면 link-local address option은 PBA 메시지에 나타나야 한다. 그렇지 않다면, link-local address option은 request 메시지에 포함되지 말아야 한다. [1]의 6.8 섹션에 기술된 consideration들은 link-layer address option을 사용할 때 적용되어야 한다.

10. PBU 메시지는 [1]의 6.9.1.5 섹션에 명시되어 있는 데로 설정되어야만 한다.

11. 만약 MN을 위한 binding update list가 존재하지 않는다면, MAG는 PBU 메시지를 전송하자마자 MN을 위한 binding update list를 설정해야만 한다.

• PBA(proxy binding acknowledgement) 수신

MAG는 LMA로부터 PBA 메시지를 수신하자마자 다음과 같이 명시된 데로 메시지를 처리해야만 한다.

1. 수신한 PBA 메시지는 [1]의 섹션 4에 명시되어 있는 것처럼 인증 과정을 거쳐야만 한다. IPsec이 메시지 인증하는데 사용된다면 수신한 패킷의 IPsec 헤더의 SPI는 security association을 하고 PBA 메시지를 인증하는 데에 필요로 한다.

2. MAG는 수신한 PBA 메시지의 mobility header를 처리할 때 [2]의 9.2절에 명시된 규칙들을 지켜야만 한다.

3. MAG는 메시지 상의 timestamp option(만약 존재한다면)과 sequence number를 처리하기 위해 [1]의 섹션 5.5에 명시된 consideration을 적용해야 한다.

4. MAG는 [2]에 명시되어 있는 것처럼 PBA 메시지에 있어 type 2 routing header와 관련있는 어떠한 checks를 무시해야 한다.

5. MAG는 최근에 전송한 request 메시지에 대한 응답으로서 일치시키기 위해 MN identifier option에 있는 MN identifier를 이용해야 한다. 하지만 만약 하나 이상의 request 메시지가 같은 MN을 위한 request queue에 존재하게 된다면 sequence number 필드는 그러한 메시지들로부터 정확한 메시지를 구분할 수 있어야 한다. 이를 구현하기 위해서는 여러 방법이 존재한다. 추가적으로 수신한 PBA 메시지가 어떠한 PBU 메시지와 일치하지 않는다면 그 메시지는 폐기해야 한다.

6. 만약 수신한 PBA 메시지가 handoff indicator option, access technology option, MN link-layer identifier option, MN identifier option 등과 같은 메시지 option을 가지며 PBU 메시지에 명시된 옵션과 다른 값을 가지고 있다면 이러한 메시지는 폐기되어야만 한다. 왜냐하면 LMA는 이러한 메시지의 옵션에 대한 echo back을 기다리고 있을 수 있기 때문이다. 이러한 경우 MAG는 관리자가 어떠한 조치를 취하기 전까지는 PBU 메시지를 재전송하지 말아야 한다.

7. 수신한 PBA 메시지의 status 필드 값이 PROXY_REG_NOT_ENABLED를 가지고 있다면 MAG는 관리자가 어떠한 조치를 취하기 전까지는 MN을 위해 다시 PBU 메시지를 전송하지 말아야 한다. 또한 해당 MN을 위한 이동성 서비스도 거부해야만 한다.

8. 만약 수신한 PBA 메시지가 TIMESTAMP_LOWER_THAN_PREV_ACCEPTED 값을 가지고 있다면 MAG는 MN의 존재를 알리기 위해 다시 등록해야만 한다. MAG는 이러한 error code를 수신하자마자 시간을 동기화시킬 필요는 없다.

9. 만약 수신한 PBA 메시지가 TIMESTAMP_MISMATCH 값을 가지고 있다면 MAG는 동기화를 위해 사용되는 common time source와 동기화를 맞춘 후에 MAG는 다시 등록해야만 한다. MAG는 수신한 메시지의 timestamp를 기준으로 LMA 시스템의 clock과 동기화를 맞추지 말아야 한다.

10. 만약 수신한 PBA 메시지가 NOT_AUTHORIZED_FOR_HOME_NETWORK_PREFIX 값을 가지고 있다면 MAG는 같은 프리픽스들을 다시 request 하지 말아야 한다. 하지만 LMA가 모두 0으로 채워진 오직 하나의 home network prefix option을 포함함으로써 프리픽스를 할당하도록 요청할 수도 있다.

11. 만약 수신한 PBA 메시지가 128 이상의 어떠한 값을 가지고 있다면 MAG는 RA 메시지에 MN의 홈네트워크 프리픽스를 advertise 하지 말아야 한다. 또한 홈네트워크 프리픽스를 이용한 주소를 가진 MN으로부터 받은 어떠한 패킷도 전송하지 않음으로써 MN으로의 이동성 서비스를 거부해야 한다. 이는 MN과 공유하고 있는 점대점 링크를 끊을 수도 있다.

12. 만약 수신한 PBA 메시지가 0(PBU가 수락됨)으로 설정되어 있다면, MAG는 LMA와 양방향 터널을 설정해야만 한다(만약 LMA와 양방향터널이 존재하지 않을 경우). [1]의 5.6.1 섹션의 고려사항은 동적으로 형성된 양방향 터널을 관리하는데 적용되어야 한다.

13. MAG는 MN과 양방향 터널을 통해 홈네트워크 프리픽스를 가진 주소를 이용하는 MN으로부터 수신한 패킷들을 전송하기 위해 route를 설정해야 한다. 생성된 터널과 라우팅 상태는 [1]의 6.10.5의 나와있는 MAG에서의 forwarding behavior를 따라야 한다.

14. MAG는 수락한 binding registration value를 반영하기 위해 binding update list를 업데이트 해야만 한다. 또한 액세스 링크로 전송하는 RA 메시지에 프리픽스를 포함함으로써 MN의 홈네트워크 프리픽스를 advertise 해야만 한다.

15. 만약 수신한 PBA 메시지가 0으로 설정되어 있는 link-local address option에 있는 주소를 가지고 있다면, MAG는 점대점 링크 상의 링크로컬 주소를 설정해야만 하며 DAD를 수행하는 것 없이 어떠한 다른 링크 로컬 주소를 설정하지 말아야 한다. 이는 액세스 링크 상에서 어떠한 다른 링크 로컬 주소와의 충돌을 방지할 것이다. 하지만 LMA로부터 생성된 만약 링크 로컬 주소가 해당 링크에서 MN으로부터 이미 사용중일 경우 MAG는 이 주소를 사용하지 말아야 하며 다른 링크 로컬 주소로 설정해야 한다. 또한 이러한 링크 로컬 주소는 LMA로 PBU 메시지를 전송하고 link-local address option에 이 주소를 포함함으로써 upload 해야 한다.

• Binding lifetime 확장

1. 현재 등록된 MN의 lifetime을 확장시키기 위해(예를 들어 동일한 MAG로부터 초기 binding 등록을 성공적으로 한 이후) MAG는 LMA로 새로운 lifetime 값을 가진 PBU 메시지를 전송할 수 있다. 이러한 재등록 메시지는 초기 PBU 메시지와 동일한 옵션을 설정하여 전송해야 한다. 이에 대한 고려사항은 [1]의 6.9.1.1 섹션에 나와 있다.

2. 해당 이동성 세션을 위해 할당된 각 홈 네트워크 프리픽스를 위한 home network prefix option이 있어야 한다.

3. Handoff indicator option에 있는 handoff indicator field는 5로 설정되어야 한다.(Handoff state not changed - Re-Registration)

• MN의 detachment와 binding de-registration

1. MN이 현재 access link로부터 멀어지거나 MN이 mobility session을 끝맺으려 한다는 것을 MAG가 감지한다면, MAG는 lifetime을 0으로 설정하고 설정한 lifetime과 PBU메시지를 LMA로 전송한다. 이 re-registration 메시지는 처음 PBU메시지의 option과 동일하게 설정되어야 한다. 그러나 다음의 예외 사항이 있다.

2. 각각의 설정된 HNP에 대한 Home Network Prefix option은 mobility session을 위하여 설정된다. 또한 Home Network Prefix option의 prefix값은 각자의 prefix값을 가진다.

3. Handoff Indicator option의 HI(handoff indicator) 필드는 4로 설정되어야 한다. HI가 4의 값을 가질 때 이는 핸드오버의 상태를 모른다는 것을 의미한다.

PBU 메시지의 응답으로 LMA는 Status field를 0으로 설정한 PBA 메시지를 MAG로 전송하거나, 응답을 기다리는 시간으로 설정된 INITIAL_BINDACK_TIMEOUT 동안 응답을 기다린 후 MAG는 다음의 절차를 수행하여야 한다.

1. MAG는 Binding Update List의 해당 MN의 Binding Update List entry를 제거해야 한다.

2. MAG는 해당 MN 트래픽의 tunneling을 위하여 생성된 routing state를 제거해야 한다.

3. 만약 해당 MN의 LMA로 tunneling이 동적으로 생성되고 tunnel을 사용하는 다른 MN이 존재하지 않는다면, tunnel은 해지되어야 한다.

4. MAG는 해당 MN과 공유되는 point-to-point link를 해지하여야 한다. 이 동작은 point-to-point link에 연결된 인터페이스상의 IPv6 address를 MN이 강제로 제거하게 한다.

• PBU 메시지 생성

MAG는 PBU메시지를 LMA로 전송할 때 다음과 같은 메시지를 구성하여야 한다.

IPv6 헤더의 Source Address 필드는 MAG의 외부(egress) 인터페이스로 할당된 global address로 설정되어야 한다. Alternate Care-of Address option이 요청(PBU) 메시지에 존재하지 않는다면 PBU메시지에서 Proxy-CoA가 Alternate Care-of Address option을 대신한다. 반면 Alternate Care-of Address option이 존재한다면 Alternate Care-of Address option에서 사용되는 주소가 Proxy-CoA를 대신하게 된다.

• RS(router solicitation) 메시지

MN은 MAG에게 RS메시지를 전송한다. MAG는 RS메시지를 수신하거나 RA메시지를 전송하기 전에 다음의 것들을 수행하여야 한다.

1. RS메시지를 전송받은 MAG는 HNP를 포함하는 RA메시지를 전송할 것이다. 하지만 MN의 HNP를 포함하는 RA메시지를 전송하기 전에, MN의 해당 LMA에 binding 등록절차를 수행하여야 한다.

2. 만약 LMA가 PBU메시지를 거절하거나 MAG가 어떤 이유로 binding 등록절차를 실패하면 MAG는 MN의 HNP를 advertise하지 않고, RA메시지를 이용하여 local visited network의 prefix를 알림으로써 MN의 일반적인 IPv6 접속을 제공한다.

3. MAG는 MN에 전송하는 RA메시지에 MTU option을 추가한다. 이것은 링크상의 MN이 advertise된 MTU값을 사용하도록 보증한다. 그리고 MTU값은 MAG와 LMA간의 양방향 터널의 MTU값을 반영한다.

• Default 라우터

PMIPv6에서 MAG는 MN이 포함되는 해당링크의 default 라우터가 된다. 하지만 MN이 다른 링크로 이동할 때 각 link의 serving MAG들은 RA메시지를 전송할 것이다. 이와 같은 경우, 이런 RA메시지들이 다른 link-local address나 link-layer address를 전송한다면 MN은 핸드오버 후 항상 새로운 default 라우터를 가지게 될 것이다. 이런 문제를 해결하기 위하여 PMIPv6 도메인상의 모든 MAG들은 값은 link-local address와 local-layer address를 이용하도록 요구된다. 이러한 address들은 PMIPv6 도메인 전반에 걸쳐 고정된 주소를 가지며 모든 MAG는 이러한 고정된 global address를 사용한다. FixedMAGLinkLocalAddressOnAllAccessLink와 FixedMAGLinkLayer AddressOnAllAccessLink는 이러한 목적으로 사용된다. 게다가 이것은 LMA가 link-local address를 생성하고 이것을 MAG에게 제공하도록 한다.

• retransmissions과 rate limiting

MAG는 LMA로 전송되는 PBU메시지의 rate 제한(limiting)과 재전송(retransmission)을 책임진다. Retransmission과 rate limiting의 역할은 [RFC3775]에서 지세히 다루고 있으며 다음에 오는 것들이 적용되어야한다.

1. MAG가 PBU메시지를 보낼 때 재전송 타이머를 설정하기 위하여 INITIAL_BINDACK_TIMEOUT을 사용한다. 이때, MAG는 InitalBindAckTimeoutFirstReg 이내의 재전송 시간을 사용하며 InitalBindAckTimeoutFirstReg 이상의 재전송 시간을 사용하지 않는다.

2. 만약 MAG가 재전송 시간 내에 registration이나 re-registration을 위한 적절한 응답을 받지 못한다면 적절한 응답을 전송받을 때까지 재전송이 이루어진다. 이때 MAG는 재전송을 하기 전에 MN이 여전히 접속되어 있는지를 확인하여야 한다.

3. MAG는 재전송이 이루어질 때마다 timeout의 두 배가 되는 exponential back-off 처리를 수행해야만 한다. 이러한 과정은 응답을 받거나 timeout이 MAX_BINDACK_TIMEOUT이 될 때까지 이루어진다.

4. Timestamp-based scheme이 사용되면, 재전송된 PBU메시지는 최근의 timestamp를 사용해야 한다. 만약 Sequence Number scheme가 사용된다면, 재전송된 PBU메시지는 이전에 전송된 PBU메시지의 Sequence Number보다 큰 Sequence Number보다 큰 값을 가지는 PBU메시지를 사용하여야 한다.

• Path MTU 탐색

MN, MAG, LMA의 정확한 MTU를 이해하는 것은 중요하다. MN이 정확한 MTU를 사용하여야 MN은 local link MTU를 초과하지 않는 패킷을 보낼 수 있으며, MAG로부터 tunneling된 패킷들이 fragment 되는 것을 예방할 수 있다. 다음사항은 MTU 탐색에 관련된 것들이다.

2.9.2. Routing Considerations

이 섹션에서는 MAG가 어떻게 MN와의 트래픽의 송, 수신을 제어하는지에 대하여 다룬다.

• Transport network

LMA와 MAG간의 전송망은 IPv6이다. [IPv4-PMIPv6]문서에서는 IPv4전송 협상과 encapsulation 모드를 부합시키기 위하여 요구되는 확장성에대하여 기술하고 있다.

• Tunneling과 encapsulation modes

HNP에서 MN이 사용하는 IPv6 address는 LMA에 의하여 앵커 된다. MN이 액세스 네트워크부터 MAG로 앵커되는 주소를 사용하기 위해서는 tunneling이 수행되어야 한다. Tunneling은 다른 IPv6 패킷이 페이로드처럼 encapsulation하여 LMA와 MAG간에 라우팅을 제공한다. 또한 네트워크의 토폴로지를 감출 수 있다(네트워크의 투명성 제공). MIPv6 표준 [RFC3775]에서는 HA와 MN간의 IPv6-over-IPv6 tunneling을 정의한다. PMIPv6에서는 이를 확장하여 MAG와 LMA간의 tunneling을 정의한다. 대다수의 OS에서 tunnel은 가상 point-to-point 인터페이스처럼 수행된다. 이 가상 인터페이스를 통하여 패킷들은 라우팅 되며, 이를 위하여 패킷들은 encapsulation된다. LMA로 point-to-point tunnel을 형성하기 위해서는 MAG는 외부로 나가는 인터페이스에 대하여 Source Address field를 global address로 설정하며 Destination Address field를 LMA의 global address로 설정한다.

․ IPv6-in-IPv6에서 IPv6 데이터그램은 IPv6 패킷으로 encapsulated된다.

IPv4-PMIPv6에서는 IPv4로의 변환을 지원하기 위하여 또 다른 encapsulation mode를 이용한다.

․ IPv6-in-IPv4에서 IPv6 데이터그램은 IPv4 패킷으로 encapsulation된다.

․ IPv6-in-IPv4-UDP에서 IPv6 데이터그램은 IPv4의 UPD 패킷으로 encapsulation된다.

․ IPv6-in-IPv4-UDP-TLV에서 IPv6 데이터그램은 TLV헤더를 가지는 IPv4의 UDP 패킷으로 encapsulation된다.

• Local routing

만약 이동한 MN과 correspondent node가 같은 MAG에 연결되어 있다면 MAG는 Local Routing을 통하여 이를 최적화한다. Local routing을 통하여 MN의 LMA로 reverse tunneling이 수행되지 않는다. 이런 path optimization 결정은 MAG의 정책에 근거하며 MN의 LMA에 의하여 결정된다.

• Tunnel management

앞에서 설명한 LMA에서의 tunnel management가 MAG에서도 적용된다.

• Forwarding rules

MN위 Home Network로 전송되는 패킷:

․ MN의 LMA에 인하여 생성된 양방향 tunnel로부터 패킷을 전송받으면 MAG는 전송받은 패킷을 포워딩하기 위하여 inner 패킷의 destination address를 이용한다. MAG는 decapsulation을 통하여 패킷을 포워딩하기 전에 outer 헤더를 제거하여야 한다. 만약 MAG가 destination address에 부합하는 인터페이스를 찾지 못한다면 해당 패킷을 폐기한다. 그리고 이를 ICMP 제어 메시지를 통하여 LMA에게 알린다. 자세한 설명은 [RFC2473]을 참조한다.

․ 일반 IPv6의 호스트와 같이 MAG에 연경되어있는 Correspondent node로부터 연결되어 있는 MN이 destination address인 패킷을 받으면 MAG는 패킷을 바로 MN으로 전송할지 여부를 판단하기 위하여 EnableMAGLocalRouting flag를 확인한다. MAG가 바로 MN으로 전송하지 않아야 한다고 판단되면 패킷을 LMA로 전송한다. 반면 MAG가 바로 MN으로 전송하여야 한다고 판단되면 바로 Mn을 패킷을 전송한다.

• MN에 의한 Forwarding Packets Sent

․ MN으로부터 패킷을 받으면 MAG는 패킷을 destination으로 바로 전송하거나 MN의 LMA로 패킷을 tunneling하기 전에 LMA와 MN이 binding되어 있는지 확인한다.

․ MN으로부터 같은 local내에 존재하는 node가 destination인 패킷을 수신하면, MAG는 패킷을 바로 destination으로 전송할지를 판단하기 위하여 EnableMAGLocalRouting flag를 확인한다. EnableMAGLocalRouting flag의 확인 결과 만약 MAG가 바로 destination으로 라우팅 되는 것을 허락하지 않는다면, MAG와 LMA간의 양방향 tunnel를 통하여 패킷이 라우팅 된다.

․ Destination이 MAG에 직접적으로 연결되어 있지 않은 패킷을 MN으로부터 전송받으면 MAG는 LMA와 MAG간에 형성된 양방향 tunnel을 통하여 전송받은 패킷을 LMA로 전송한다. 이때 패킷이 link-local source address를 가진다면 포워드 되지 않는다.

․ IPv6로 encapsulation된 패킷은 그림1과 같은 구조를 가지며 페이로드가 IPsec에 의하여 보호된다면 그림2와같은 구조를 가진다.

• Access link상의 address configuration에 기반한 supporting DHCP

본 섹션에서는 PMIPv6 도메인에서 이용 가능한 DHCP를 이용한 안정적인 Address Configuration방법을 설명한다. 또한 DHCP

․ DHCP를 이용하여 안정적인 Address Configuration를 제공하기 위해서는 DHCP Relay Agent 서비스가 PMIPv6상의 모든 MAG에서 제공되어야 한다. 게다가 DHCP Relay Agent는 unicast address를 포함하는 destination address의 list나 All_DHCP_Servers multicast address, 그밖에 요구된 주소를 이용하기 위하여 configuration되어야 한다.

․ DHCP 인프라는 각각의 설정된 prefix에서 PMIP 도메인의 link로 주소를 설정하기위하여 configuration되어야 한다. DHCP relay agent는 MN이 포함되는 link를 가리킨다.

• Home Network Prefix Renumbering

만약 MN의 HNP가 재할당되거나 이동 세션 중에 사용할 수 없게 된다면 MAG는 prefix lifetime을 0으로 설정한 RA메시지를 이용하여 prefix를 회수하여야 한다. 또한 LMA와 MAG는 prefix 재할당을 위하여 생성된 라우팅 상태를 제거하여야 한다.

• Mobile Node Detachment Detection and Resource Cleanup

MN의 현재 binding의 lifetime을 갱신하기 위하여 PBU메시지를 LMA로 전송하기 전에 MAG는 MN이 링크에 연결되어 있음을 확실하게 하여야 한다. 만약 MAG가 현제 연결되어있는 링크를 탐지할 수 없다면 MN의 registration lifetime을 갱신할 수 없다. 게다가 이런 경우 MAG는 MN의 LMA로 lifetime을 0으로 설정한 PBU미시지를 보냄으로써 MN의 binding을 종결시켜야 한다. 또한 MN을 위하여 생성된 Binding Update List entry와 같은 local state를 제거하여야 한다.

• Allowing Network Access to Other IPv6 Nodes

MIPv6 환경에서 네트워크 제공자는 MN에게 이동성을 제공하며 보통의 node에게는 일반적인 IP를 제공하기 위하여 MAG를 사용한다. 또한 이를 위하여서 네트워크는 MN에 네트워크 기반의 이동성을 제어할 수 있어야하며 이때 일반적인 IPv6 기반이 되어야 한다.

링크상의 MN을 탐색하고 정책을 수립한 후 MAG는 MN이 네트워크 기반의 이동성 관리 서비스가 받을지 여부를 판단해야 한다. 만약 MN이 네트워크 기반의 이동성 관리 서비스를 받아야 한다면 MAG는 L3연결에 관한 변화를 감지하지 않은 MN이 있는지 확인하여야 한다.

만약 MN이 네트워크 기반의 이동성 관리 서비스를 제공받지 않는다면 MAG는 MN에게 일반적인 IPv6를 제공하도록 선택할 수 있다. IPv6는 액세스가 활성화되면 MN는 일반적인 IPv6 address configuration 절차를 사용하여 IPv6 address를 얻을 수 있을 것이다. 이것은 기본적으로 MN이 액세스 링크에 접속하고 단말기반의 이동성 프로토콜 이용 시 충돌을 피하기 위하여 MAG 기능이 일반 액세스 라우터와 같은 작동함을 보장한다.