IP

TCP/IP에서 두 host 간의 모든 Link Layer Protocol이 모두 같은 MTU를 가진다면 IP Fragementation이 없어도 되지 않을까?

IP Layer에서 Fragmentation이라는 기능은 Datagram을 쪼개서 Link Layer로 보낼 수 있는 기능입니다. 중간 경로에서 어떤 Link Layer Protocol을 사용할지 알 수 없기 때문에 Host가 자신이 사용하는 Link Layer Protocol의 MTU에 맞게 보낸다고 해도 중간 과정에 Router가 더 작은 MTU를 가지는 Link Layer로 보내야하는 경우가 생길 수 있습니다. 이때, Fragmentation을 통해 Datagram을 MTU에 맞게 쪼개서 보낼 수 있습니다.

그런데 TCP/IP에서 두 host 간의 모든 MTU가 예를 들어 1500 Byte라고 알고 있다면 Fragmentation이 필요 없지 않을까요? Application에서 TCP로 보내는 Byte stream은 1500 Byte보다 클 수 있지만, MSS보다 작게 TCP Segment를 만들테니 Host의 IP에서도 굳이 Fragmentation할 필요 없을 것 같습니다. 이러면 중간 네트워크 장비에서 오버헤드가 줄어들어서 좋을 것 같습니다.

실제로 IPv6에서는 경로 상의 가장 작은 MTU를 알아내는 방법으로 Fragmenation을 없앴다고 합니다. 정확하게는, 중간 Router의 Fragmentation은 불가능하고 Host의 Fragmentation은 가능은 하다고 합니다.

Host와 Link간의 경계 Interface

Router는 여러 네트워크에 연결되기 때문에 여러 IP Address를 가져야 합니다. 이 IP Address를 logical interface로 생각할 수 있습니다.¹

We define a logical [network] interface to be a logical path, distinguished by a unique IP address, to a connected network. — RFC 1122 Logical [network] interface Terminology

Capturing packets from an execution of traceroute

traceroute라는 도구를 이용해서 gaia.cs.umass.edu까지의 경로상의 Rotuer들을 파악해봅니다. 동시에 Wireshark로 ICMP Packet을 캡처합니다. 윈도우 tracert는 payload의 크기를 설정할 수 있는 기능이 없어서 교재에서 제공하는 trace 파일을 직접 다운받아서 진행합니다.

Part 1: Basic IPv4

Traceroute는 TTL을 1부터 증가시켜가면서 UDP 패킷을 보냅니다. 그리고 라우터는 TTL이 0이되면 ICMP 형식의 패킷을 응답합니다. 이 패킷 안에 해당 Router와 관련된 정보가 들어있습니다.

1. Select the first UDP segment sent by your computer via the traceroute command to gaia.cs.umass.edu. (Hint: this is 44th packet in the trace file in the ip-wireshark-trace1-1.pcapng file in footnote 2). Expand the Internet Protocol part of the packet in the packet details window.

   • What is the IP address of your computer?

     Internet Protocol Version 4, Src: 192.168.86.61, Dst: 128.119.245.12
     0100 .... = Version: 4
     .... 0101 = Header Length: 20 bytes (5)
     Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
     Total Length: 56
     Identification: 0xfda1 (64929)
     000. .... = Flags: 0x0
     ...0 0000 0000 0000 = Fragment Offset: 0
     Time to Live: 1
     Protocol: UDP (17)
     Header Checksum: 0x2faa [validation disabled]
     [Header checksum status: Unverified]
     Source Address: 192.168.86.61
     Destination Address: 128.119.245.12
     [Stream index: 4]
     첫 번째 패킷 번호는 44번이고, IP 헤더를 확인하면 192.168.86.61이 내 IP 주소인 것을 알 수 있습니다.

2. What is the value in the time-to-live (TTL) field in this IPv4 datagram’s header?

   TTL이 1로 설정되어있습니다.

3. What is the value in the upper layer protocol field in this IPv4 datagram’s header? [Note: the answers for Linux/MacOS differ from Windows here]. traceroute로 길이가 56인 UDP Datagram을 보냈습니다. IP의 프로토콜 필드를 보니 UDP(17)입니다.

   윈도우의 tracert는 UDP Datagram을 보내는 것이 아니라 ICMP Echo Request를 담아서 보낸다고 합니다.

4. How many bytes are in the IP header?

   IPv4의 헤더는 옵션이 없는 경우 20바이트입니다.

5. How many bytes are in the payload of the IP datagram? Explain how you determined the number of payload bytes.

   UDP를 담고 있는 IP Datagram이 56바이트려면, UDP Segment는 20바이트를 뺀 36바이트여야 합니다.

6. Has this IP datagram been fragmented? Explain how you determined whether or not the datagram has been fragmented.

   Fragment에 관련된 Flag가 켜져있지 않아서 Fragmentation되지 않았음을 알 수 있습니다. 정확하게는 MF(다음 fragement가 있음)이 0이고, Fragement offset이 0인걸로 알 수 있습니다.

   호스트의 IP 스택은 가급적 Datagram이 MTU 이내의 크기가 되도록 Segment를 만들어서 Fragementation이 일어나지 않게 한다고 합니다.

이번엔 ip.src==192.168.86.61 and ip.dst==128.119.245.12 and udp and !icmp로 필터링해서 내 컴퓨터가 보낸 UDP Packet들만 확인해보겠습니다.

7. Which fields in the IP datagram always change from one datagram to the next within this series of UDP segments sent by your computer destined to 128.119.245.12, via traceroute? Why?

   한 번에 3개의 UDP Datagram을 보내는데, 3개 단위로 TTL이 1씩 증가하고 있습니다. traceroute가 이렇게 보내는 이유는 128.119.245.12사이에 존재하는 모든 Router에게서 TTL Excedded를 일으켜서 IMCP 오류 응답을 받기 위해서입니다.

   추가적으로 Identification 필드도 계속 증가하고 있습니다. IP 스택이 할당해주는 것 같습니다.

8. Which fields in this sequence of IP datagrams (containing UDP segments) stay constant? Why?

   UDP의 Destination Port와 TTL, Identification, Checksum을 제외하고는 나머지는 모두 바뀌지 않습니다.

9. Describe the pattern you see in the values in the Identification field of the IP datagrams being sent by your computer.

   1씩 증가하고 있습니다.

이제 ip.dst==192.168.86.61 and icmp로 ICMP TTL Exceeded 응답 패킷을 확인합니다.

10. What is the upper layer protocol specified in the IP datagrams returned from the routers? [Note: the answers for Linux/MacOS differ from Windows here].

    Internet Protocol Version 4, Src: 68.87.181.105, Dst: 192.168.86.61
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
    Total Length: 576
    Identification: 0x1ab5 (6837)
    000. .... = Flags: 0x0
    ...0 0000 0000 0000 = Fragment Offset: 0
    Time to Live: 61
    Protocol: ICMP (1)
    Header Checksum: 0x5062 [validation disabled]
    [Header checksum status: Unverified]
    Source Address: 68.87.181.105
    Destination Address: 192.168.86.61
    [Stream index: 8]

    IP datagram에 Protocol은 ICMP(1)이라고 표시되어 있습니다. 윈도우나 Mac이나 Router가 응답할 때는 ICMP Protocol만 사용할텐데 왜 운영체제마다 다르다고 하는지 모르겠습니다.

11. Are the values in the Identification fields (across the sequence of all of ICMP packets from all of the routers) similar in behavior to your answer to question 9 above?

    한 라우터를 기준으로 보면 Identification field를 비슷하게 1씩 증가해가면서 응답하는 것 같습니다. 다른 IP Packet을 응답해서 증가하는 경우도 있으니 꼭 연속하지는 않습니다.

12. Are the values of the TTL fields similar, across all of ICMP packets from all of the routers?

    멀리 떨어진 Rotuer에서 온 응답일수록 TTL이 작을 것이라고 생각했는데 애초에 보낼때의 TTL값이 달라서 그런지 서로 조금씩 다릅니다.

Part 2: Fragmentation

이번엔 traceroute로 3000바이트의 UDP Datagram을 보낸 패킷을 확인해봅니다. Ethernet의 MTU는 1500이므로 아마도 Fragementation이 일어난 것을 볼 수 있을 것입니다.

13. Find the first IP datagram containing the first part of the segment sent to 128.119.245.12 sent by your computer via the traceroute command to gaia.cs.umass.edu, after you specified that the traceroute packet length should be 3000. (Hint: This is packet 179 in the ip-wireshark-trace1-1.pcapng trace file in footnote 2. Packets 179, 180, and 181 are three IP datagrams created by fragmenting the first single 3000-byte UDP segment sent to 128.119.145.12).

    • Has that segment been fragmented across more than one IP datagram? (Hint: the answer is yes!)

      No	Time (s)	Source	Destination	Protocol	Length	Info
      179	12.788154	192.168.86.61	128.119.245.12	IPv4	1514	Fragmented IP protocol (proto=UDP 17, off=0, ID=fda2)
      180	12.788155	192.168.86.61	128.119.245.12	IPv4	1514	Fragmented IP protocol (proto=UDP 17, off=1480, ID=fda2)
      181	12.788155	192.168.86.61	128.119.245.12	UDP	54	Reassembled datagram (64929 → 33435, Len=2972)

      세 개의 IP Datagram은 Identification이 같습니다. 따라서 Fragementation이 일어났음을 알 수 있습니다.

14. What information in the IP header indicates that this datagram been fragmented?

    세 개의 IP Datagram은 Identification이 같습니다. 따라서 Fragementation이 일어났음을 알 수 있습니다.

15. What information in the IP header for this packet indicates whether this is the first fragment versus a latter fragment?

    MF가 set되었고 Offset이 0인 패킷이 가장 첫 fragement임을 알 수 있습니다.

16. How many bytes are there in is this IP datagram (header plus payload)?

    첫 번째 Fragment는 정확히 1500 Byte입니다.

17. Now inspect the datagram containing the second fragment of the fragmented UDP segment. What information in the IP header indicates that this is not the first datagram fragment?

    MF가 set되었는데 Offset이 0이 아니기 때문에 첫 번째 fragment가 아님을 알 수 있습니다.

18. What fields change in the IP header between the first and second fragment?

    Identification은 같고, Fragment offset이 바뀌었습니다. 따라서 Header checksum도 바뀌었습니다.

19. Now find the IP datagram containing the third fragment of the original UDP segment. What information in the IP header indicates that this is the last fragment of that segment?

    MF가 set되지 않았는데, Fragment Offset이 2960이므로 마지막 Fragment임을 알 수 있습니다.

    총 3000 바이트의 IP Datagram이 $(20 + 1480) + (20 + 1480) + (20 + 20)$ 세 개의 Fragment로 쪼개졌습니다. 단순히 1500길이의 IP Dagaram 두 개로 안되는 이유는, UDP Datagram이 2980바이트이고, 1500길이의 IP Dagaram을 두 개 보내면 1480 * 2 = 2960으로 20 바이트가 부족하기 때문입니다. 따라서 한 번 더 보내야 합니다.

Part 3: IPv6

교재에서 제공해준 trace 파일에서 IPv6 DNS 패킷을 살펴봅니다.

Internet Protocol Version 6, Src: 2601:193:8302:4620:215c:f5ae:8b40:a27a, Dst: 2001:558:feed::1
    0110 .... = Version: 6
    .... 0000 0000 .... .... .... .... .... = Traffic Class: 0x00 (DSCP: CS0, ECN: Not-ECT)
    .... 0110 0011 1110 1101 0000 = Flow Label: 0x63ed0
    Payload Length: 37
    Next Header: UDP (17)
    Hop Limit: 255
    Source Address: 2601:193:8302:4620:215c:f5ae:8b40:a27a
    Destination Address: 2001:558:feed::1
    [Stream index: 1]
User Datagram Protocol, Src Port: 64430, Dst Port: 53
    Source Port: 64430
    Destination Port: 53
    Length: 37
    Checksum: 0x3953 [unverified]
    [Checksum Status: Unverified]
    [Stream index: 3]
    [Stream Packet Number: 1]
    [Timestamps]
    UDP payload (29 bytes)
Domain Name System (query)
    Transaction ID: 0x920d
    Flags: 0x0100 Standard query
    Questions: 1
    Answer RRs: 0
    Authority RRs: 0
    Additional RRs: 0
    Queries
    [Response In: 27]

20. What is the IPv6 address of the computer making the DNS AAAA request? This is the source address of the 20th packet in the trace. Give the IPv6 source address for this datagram in the exact same form as displayed in the Wireshark window.

    2601:193:8302:4620:215c:f5ae:8b40:a27a입니다.

21. What is the IPv6 destination address for this datagram? Give this IPv6 address in the exact same form as displayed in the Wireshark window.

    2001:558:feed::1입니다. :와 :사이의 16비트가 모두 0이여서 생략되었습니다.

22. What is the value of the flow label for this datagram?

    0x63ed0입니다.

23. How much payload data is carried in this datagram?

    37 바이트입니다.

24. What is the upper layer protocol to which this datagram’s payload will be delivered at the destination?

    Next Header field에서 UDP(17)임을 알 수 있습니다.

25. How many IPv6 addresses are returned in the response to this AAAA request?

    Domain Name System (response)
    Transaction ID: 0x920d
    Flags: 0x8180 Standard query response, No error
    Questions: 1
    Answer RRs: 1
    Authority RRs: 0
    Additional RRs: 0
    Queries
    Answers
        youtube.com: type AAAA, class IN, addr 2607:f8b0:4006:815::200e
    [Request In: 20]
    [Time: 140.916000 milliseconds]

    AAAA Record 요청에 대해 Answer RRs: 1을 확인할 수 있습니다.

26. What is the first of the IPv6 addresses returned by the DNS for youtube.com (in the ip-wireshark-trace2-1.pcapng trace file, this is also the address that is numerically the smallest)? Give this IPv6 address in the exact same shorthand form as displayed in the Wireshark window.

    2607:f8b0:4006:815::200e입니다.