🚀 go-pugleaf

Hi, I am writing an ftp app which I am currently endeavoring to incorporate
IPv6 support for.  I have read and read and re-read RFC 2373 but I have to
admit, it is boggling my mind....

Ok, I understand the bit about the 8 segments of 16 bit hex values. So far
so good. What I don't understand(as described in section 2.3) is the text
representation of the prefixes such as

12AB:0000:0000:CD30:0000:0000:0000:0000/60

... honestly, this is where they lose me. What IS the /60 for? I am stumped.

In section 2.5.6, it describes IPX addressing where the high 7 bits is
stripped. This makes no sense to me at all. Ok, stripped is not the correct
term, perhaps I should be saying that it is reserved for the value of
0000010. Again, I am totally confused by this construct.

Further to this, I understand using the Local Interface in the low end 64
bits of the representation. This makes perfect sense and is a good idea
because it helps to route back to a NAT address. Finally, a part I
understand.... ;)

So in trying to implement this by using both RFC 2373 and RFC 2428, I have
the following example...

EPRT |1|209.210.211.212|2546|

Ok, THIS I understand, the 1 is requesting to use IPv4 but using the
extended protocol syntax, the middle section is just TOO easy and the last
part is requesting port 2546..... this is no problem to me... but...

EPRT |2|1080::8:800:200C:417A|5282|

    is just too weird. I know that the 2 is saying to use IPv6, and I know
that it is requesting port 5282, but why are there only 6 other segments in
the middle delimited section? And why is there a double colon in there? Is
this some kind of abbreviation? And if so, when parsing such a response to
an EPSV command, what do I assume with the double colon section?

Should the middle delimited section have 8 segments in 16 bit hex values?
Like when I see this...

|0:0:0:0:0:0:0:1|

I know that this is a loopback address, but at least I know it has 8
segments to it.


Are there any other resources I can read to gain more insight into this
standard? You have to be a bloody lawyer to understand the terminology when
reading RFC's... <g>

Thank you for listening and I hope this is not as confusing to others as it
is to me, because it quite simply gives me a headache looking at it.

Lynn