최근 , 인터넷 은 주소 의 고갈 에 따라 IPv 4 에서 IPv 6 로 진화 되 고 있 다 . 따라서 , IPv 6 주소 체계 하 에서 전송 되 는 프레임 의 헤드 들 도 인터넷 프로토콜 헤드 의 단순 화 뿐 만 아니 라 규격화 를 통하 여 라우터 에서 단순 처리 를 할 수 있 도록 변경 하 였 다 . 한편 , IPv 6 에서 도 인터넷 QoS 를 제공 하 기 위하 여 IPv 4 에서 사용 하 던 DSCP ( DiffServ Code Point ) 방식 과 동일 하 게 트래픽 들 의 그룹 으로 묶 어 처리 하 는 TC ( Traffic Class ) 를 지원 하 는 방안 과 사용 자 들 간 의 세션 맺 음 을 통하 여 세션 에 적당 한 QoS 파라 메터 를 라우터 에 알려 주 고 향후 전송 되 는 패킷 에서 는 이 를 구분 할 수 있 도록 플로우 레이블 ( FlowLabel ) 을 사용 하 는 방법 이 있 다 . 플로우 레이블 을 이용 하 는 경우 플로우 별로 서비스 품질 보장 과 연속 되 는 플로우 의 데이터 를 빠른 처리 를 위하 여 플로우 레이블 을 이용 하 자는 표준 이 제안 되 고 있 다 . 즉 , IPv 6 의 플로우 레이블 을 이용 하 면 망 창치 에서 IPv 6 헤드 가 다중 으로 붙 은 패킷 을 수신 할 때 , 모든 헤드 들 을 확인 하 지 않 고 첫 번 째 헤드 의 플로우 레이블 을 통하 여 각 스프 림 을 구분 하 며 또한 각 세션 별 로 차별 화 할 수 있 다 . 그러나 , 플로우 레이블 을 완벽 하 게 사용 하 기 위하 여 , 단말 에서 세션 을 맺 을 때 마다 RSVP ( Resource Reservation Protocol ) 등 의 신호 프로토콜 을 이용 한 플로우 구분 과 적절 한 QoS 파라 메터 의 맵 핑 등 을 통하 여 세션 을 구분 하 고 관리 하 여야 하 는 기능 들 이 필요 하 다 . 이러 한 기능 을 이용 할 때 라우터 에서 는 너무 많 은 신호 들 을 처리 하 여야 하 기 때문 에 오버헤드 등 으로 망 에 적용 되 기 쉽 지 않 는 단점 이 있 다 .