Initial IPv6 support

RFC PATCH Superseded Chris Packham 6 participants 22 messages Jan 18, 2013 – Jan 21, 2013

Subsystems (3)

Networking Library code Vsprintf

lore

Share & tools

lore

Chris Packham

author

2013-01-18 01:35 UTC #0 lore raw

v2 cover Initial IPv6 support

From: Chris Packham <[email protected]>

This series so far covers the introduction of a IP6addr_t and printing/parsing of addresses. I have a patch for testing these basic things which I haven't included in this series yet. Is there a unittest facility for u-boot I should be using?

A few open questions

1) Presumably the majority of the actual V6 code would be included by a config option (CONFIG_IPV6). How far should I take that? Should the vsprintf code be conditional?

2) Our current out of tree code parallels net.c and net.h. Should I continue this for the final version or integrate it into net.[ch].

3) rxhand_f currently takes an IPaddr_t. I haven't looked at the usage of this yet but to support V6 this may need to be a new union or a void *.

Changes in v2:
-use __be16/__be32
-add ipv6_addr_v4mapped and ipv6_addr_is_isatap inline functions -Add support for printing mapped and ISATAP addresses

Chris Packham (5):
Initial net6.h
lib/vsprintf.c: add IPv6 compressed format %pI6c lib/net_utils.c: make string_to_ip stricter lib/net_utils.c: add string_to_ip6 common.h: add getenv_IP6addr

 include/common.h |   6 +++
 include/net6.h   |  59 +++++++++++++++++++++++
 lib/net_utils.c  | 117 ++++++++++++++++++++++++++++++++++++++++++++-
 lib/vsprintf.c   | 143 +++++++++++++++++++++++++++++++++++++++++++++++--------
 4 files changed, 304 insertions(+), 21 deletions(-)
 create mode 100644 include/net6.h

Signature · 1 line

1.7.12.rc2.16.g034161a

Chris Packham

author

2013-01-18 01:35 UTC #1 lore raw

RFC PATCH v2 1/5 Initial net6.h

From: Chris Packham <[email protected]>

Has the definition of an IPv6 address and IPv6 header. It may make sense to separate the v4 support from net.h (or to include this in net.h).

Signed-off-by Chris Packham <[email protected]>

---
Changes in v2:
-use __be16/__be32
-add ipv6_addr_v4mapped and ipv6_addr_is_isatap inline functions

 include/net6.h | 43 +++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 43 insertions(+)
 create mode 100644 include/net6.h

include/net6.h new file +43 -0

new file mode 100644
index 0000000..03bccb2
@@ -0,0 +1,43 @@
+/**
+ * Simple IPv6 network layer implementation.
+ *
+ * Based and/or adapted from the IPv4 network layer in net.[hc]
+ *
+ * (C) Copyright 2013 Allied Telesis Labs NZ
+ *
+ * This file is released under the terms of GPL v2 and any later version.
+ * See the file COPYING in the root directory of the source tree for details.
+ */
+#ifndef __NET6_H__
+#define __NET6_H__
+
+typedef union ip6addr_t {
+	__u8	u6_addr8[16];
+	__be16	u6_addr16[8];
+	__be32	u6_addr32[4];
+} IP6addr_t;
+
+/**
+ * struct ipv6hdr - Internet Protocol V6 (IPv6) header.
+ *
+ * IPv6 packet header as defined in RFC 2460.
+ */
+struct ip6_hdr {
+#if defined(__LITTLE_ENDIAN_BITFIELD)
+	__u8    priority:4,
+		version:4;
+#elif defined(__BIG_ENDIAN_BITFIELD)
+	__u8    version:4,
+		priority:4;
+#else
+#error  "Please fix <asm/byteorder.h>"
+#endif
+	__u8		flow_lbl[3];
+	__be16		payload_len;
+	__u8		nexthdr;
+	__u8		hop_limit;
+	IP6addr_t	saddr;
+	IP6addr_t	daddr;
+};
+
+#endif /* __NET6_H__ */

Signature · 1 line

1.7.12.rc2.16.g034161a

Kim Phillips

2013-01-18 21:15 UTC #2 lore raw

RFC PATCH v2 1/5 Initial net6.h

Quoted 8 lines · On Fri, 18 Jan 2013 14:35:28 +1300 Chris Packham <[email protected]>…

From: Chris Packham <[email protected]>
Has the definition of an IPv6 address and IPv6 header. It may make sense to separate the v4 support from net.h (or to include this in net.h).
Signed-off-by Chris Packham <[email protected]>
---

Reviewed-by Kim Phillips <[email protected]>

Quoted 11 lines

NOTICE: This message contains privileged and confidential information intended only for the use of the addressee named above. If you are not the intended recipient of this message you are hereby notified that you must not disseminate, copy or take any action in reliance on it. If you have received this message in error please notify Allied Telesis Labs Ltd immediately.
Any views expressed in this message are those of the individual sender, except where the sender has the authority to issue and specifically states them to be the views of Allied Telesis Labs.

get rid of this message; this is a public forum.

Kim

Chris Packham

author

2013-01-18 01:35 UTC #3 lore raw

RFC PATCH v2 2/5 lib/vsprintf.c: add IPv6 compressed format %pI6c

In reply to Chris Packham

From: Chris Packham <[email protected]>

Add support for "human friendly" IPv6 address representations as specified in
http://tools.ietf.org/html/draft-ietf-6man-text-addr-representation-00

This code has been adapted from Linux kernel with minimal modification.

Signed-off-by Chris Packham <[email protected]>

---
Changes in v2:
-Add support for printing mapped and ISATAP addresses

 include/net6.h |  13 ++++++
 lib/vsprintf.c | 143 +++++++++++++++++++++++++++++++++++++++++++++++++--------
 2 files changed, 136 insertions(+), 20 deletions(-)

include/net6.h +13 -0

index 03bccb2..bdb4326 100644
@@ -40,4 +40,17 @@ struct ip6_hdr {
 	IP6addr_t	daddr;
 };
 
+/* ::ffff:0:0/96 is reserved for v4 mapped addresses */
+static inline int ipv6_addr_v4mapped(const IP6addr_t *a)
+{
+	return (a->u6_addr32[0] | a->u6_addr32[1] |
+			(a->u6_addr32[2] ^ htonl(0x0000ffff))) == 0;
+}
+
+/* Intra-Site Automatic Tunnel Addressing Protocol Address */
+static inline int ipv6_addr_is_isatap(const IP6addr_t *a)
+{
+	return (a->u6_addr32[2] | htonl(0x02000000)) == htonl(0x02005EFE);
+}
+
 #endif /* __NET6_H__ */

lib/vsprintf.c +123 ~~-20~~

189 lines not on this page · raw message

Signature · 1 line

1.7.12.rc2.16.g034161a

Chris Packham

author

2013-01-18 01:35 UTC #4 lore raw

RFC PATCH v2 3/5 lib/net_utils.c: make string_to_ip stricter

In reply to Chris Packham

From: Chris Packham <[email protected]>

Previously values greater than 255 were implicitly truncated. Add some stricter checking to reject addresses with components >255.

With the input "1234192.168.1.1" the old behaviour would truncate the address to 192.168.1.1. New behaviour rejects the string outright and returns 0, which for the purposes of IP addresses can be considered an error.

Signed-off-by Chris Packham <[email protected]>

---
Changes in v2: None

 lib/net_utils.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

lib/net_utils.c +2 -1

index b425a68..2b20ccb 100644
@@ -39,8 +39,9 @@ IPaddr_t string_to_ip(const char *s)
 
 	for (addr=0, i=0; i<4; ++i) {
 		ulong val = s ? simple_strtoul(s, &e, 10) : 0;
+		if (val > 255)
+			return 0;
 		addr <<= 8;
-		addr |= (val & 0xFF);
 		if (s) {
 			s = (*e) ? e+1 : e;
 		}

Signature · 1 line

1.7.12.rc2.16.g034161a

Chris Packham

author

2013-01-18 01:35 UTC #5 lore raw

RFC PATCH v2 4/5 lib/net_utils.c: add string_to_ip6

In reply to Chris Packham

From: Chris Packham <[email protected]>

string_to_ip6 parses an IPv6 address from a string. Parsing v6 addresses is a bit more complicated than parsing v4 because there are a number of different formats that can be used.

Signed-off-by Chris Packham <[email protected]>

---
I'm sure the parsing can be better and done in less code with only a single pass but I haven't yet figured it out. The main problem is that "::" can represent a variable number of contiguous "0000:" so when parsing "::" we can't tell how many half words to skip.

Changes in v2: None

 include/net6.h  |   3 ++
 lib/net_utils.c | 115 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 118 insertions(+)

include/net6.h +3 -0

index bdb4326..55ab187 100644
@@ -53,4 +53,7 @@ static inline int ipv6_addr_is_isatap(const IP6addr_t *a)
 	return (a->u6_addr32[2] | htonl(0x02000000)) == htonl(0x02005EFE);
 }
 
+/* Convert a string to an ipv6 address */
+extern int string_to_ip6(const char *s, IP6addr_t *addr);
+
 #endif /* __NET6_H__ */

lib/net_utils.c +115 -0

124 lines not on this page · raw message

Signature · 1 line

1.7.12.rc2.16.g034161a

Chris Packham

author

2013-01-18 01:35 UTC #6 lore raw

RFC PATCH v2 5/5 common.h: add getenv_IP6addr

In reply to Chris Packham

From: Chris Packham <[email protected]>

Analogous to getenv_IPaddr but for IPv6. This allows the caller to get an IP6addr_t from an environment variable.

Signed-off-by Chris Packham <[email protected]>

---
Changes in v2: None

 include/common.h | 6 ++++++
 lib/net_utils.c  | 1 -
 2 files changed, 6 insertions(+), 1 deletion(-)

include/common.h +6 -0

index 2f2578b..41c5fb2 100644
@@ -833,6 +833,12 @@ static inline IPaddr_t getenv_IPaddr(char *var)
 	return string_to_ip(getenv(var));
 }
 
+#include <net6.h>
+static inline int getenv_IP6addr(char *var, IP6addr_t *a)
+{
+	return string_to_ip6(getenv(var), a);
+}
+
 /*
  * CONSOLE multiplexing.
  */

lib/net_utils.c +0 -1

index a8de103..44c414f 100644
@@ -27,7 +27,6 @@
  */
 
 #include <common.h>
-#include <net6.h>
 #include <linux/ctype.h>
 
 IPaddr_t string_to_ip(const char *s)

Signature · 1 line

1.7.12.rc2.16.g034161a

Albert ARIBAUD

2013-01-18 08:20 UTC #7 lore raw

v2 cover Initial IPv6 support

In reply to Chris Packham

Hi Chris,

Quoted 4 lines · Chris Packham

From: Chris Packham <[email protected]>
This series so far covers the introduction of a IP6addr_t and printing/parsing of addresses.

As a general comment, I heartily welcome IPv6 support (even though I suspect there is quite a lot to be done on it, if only configuration), but I wonder how this fits in with the general line of not adding dead code in U-Boot. Will we make an exception for IPv6 and accept this RFC once it is officially submitted? Or do we collect small, reviewable RFCs for various IPv6 aspects but apply them in one go? Or do we create a branch or tree where IPv6 will get integrated step by step until solid enough for mainline inclusion? Or was this decided already and I missed it?

Amicalement,

Signature · 1 line

Albert.

Chris Packham

author

2013-01-18 09:39 UTC #8 lore raw

v2 cover Initial IPv6 support

Quoted 20 lines · Albert ARIBAUD

Hi Chris,
Quoted 4 lines · Chris Packham
From: Chris Packham <[email protected]>
This series so far covers the introduction of a IP6addr_t and printing/parsing of addresses.
As a general comment, I heartily welcome IPv6 support (even though I suspect there is quite a lot to be done on it, if only configuration), but I wonder how this fits in with the general line of not adding dead code in U-Boot. Will we make an exception for IPv6 and accept this RFC once it is officially submitted? Or do we collect small, reviewable RFCs for various IPv6 aspects but apply them in one go? Or do we create a branch or tree where IPv6 will get integrated step by step until solid enough for mainline inclusion? Or was this decided already and I missed it?

Quoted 2 lines

Amicalement,

Good question. Basically we have some out of tree code that implements a basic IPv6 stack. I'm drip feeding the code in pieces to avoid just dumping it on people and because the current code wouldn't meet u-boot's standards.

Putting my IPv6 promoter hat on I hope that it won't stay dead for long :)

Personally I'm happy to have a long running series and periodically send updates to the list. I have a repository on github[1] which has an ipv6 branch collecting my changes if anyone wants to pull it down for their own testing. If we want to apply some of the simple stuff early that's fine by me.

Regards,
Chris
--
[1] git://github.com/cpackham/u-boot.git

Sergey Lapin

2013-01-18 10:16 UTC #9 lore raw

v2 cover Initial IPv6 support

Quoted 1 line · Chris Packham

Putting my IPv6 promoter hat on I hope that it won't stay dead for long :)

Wolfgang Denk

2013-01-18 10:44 UTC #10 lore raw

v2 cover Initial IPv6 support

In reply to Chris Packham

Dear Chris,

Quoted 5 lines · In message <[email protected]> you wrote:

Good question. Basically we have some out of tree code that implements a basic IPv6 stack. I'm drip feeding the code in pieces to avoid just dumping it on people and because the current code wouldn't meet u-boot's standards.

Can you please go into abit more detail which exact services this implements, and how?

Last time I checked (about 2 years ago) there was no officially agreed-on standard for example how network booting should be done in IPv6.

There used to be a document how TFTP could handle IPv6 addresses at
http://datatracker.ietf.org/idtracker/draft-evans-tftp-address-options/comment/50586/
but this apears to be gone now. The proposal was rejected by then, and the comments ("I do recommend the transition to a better transport protocol.") sounded as if the IETF would like to abandon TFTp under IPv6.

I found links for DHCPv6, for example
http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-opt-netboot-00
but no read standard for a bootstrap protocol. Some documents indicated it might be based on iSCSI - but that would be quite complex; see
http://tools.ietf.org/html/rfc4173
http://tools.ietf.org/agenda/72/slides/dhc-12.pdf

So what exactly are you targeting for?

Quoted 1 line

Putting my IPv6 promoter hat on I hope that it won't stay dead for long :)

Thanks, appreciated!

Quoted 5 lines

Personally I'm happy to have a long running series and periodically send updates to the list. I have a repository on github[1] which has an ipv6 branch collecting my changes if anyone wants to pull it down for their own testing. If we want to apply some of the simple stuff early that's fine by me.

I see no problem with handling this as a branch (for example in the u-boot-net or u-boot-testing repositories). This should probably be decided by Joe Hershberger, though.

Best regards,

Wolfgang Denk

Signature · 4 lines

DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"It's like deja vu all over again."                      - Yogi Berra

Joe Hershberger

2013-01-18 18:41 UTC #11 lore raw

v2 cover Initial IPv6 support

Quoted 9 lines · Wolfgang Denk

Dear Chris,
Quoted 5 lines · In message <[email protected]> you wrote:
Personally I'm happy to have a long running series and periodically send updates to the list. I have a repository on github[1] which has an ipv6 branch collecting my changes if anyone wants to pull it down for their own testing. If we want to apply some of the simple stuff early that's fine by me.

Quoted 3 lines

I see no problem with handling this as a branch (for example in the u-boot-net or u-boot-testing repositories). This should probably be decided by Joe Hershberger, though.

I'm fine with hosting these changes as a branch in the u-boot-net repo.

-Joe

Chris Packham

author

2013-01-20 09:47 UTC #12 lore raw

v2 cover Initial IPv6 support

Quoted 10 lines · Joe Hershberger

Quoted 9 lines · Wolfgang Denk
Dear Chris,
Quoted 5 lines · In message <[email protected]> you wrote:
Personally I'm happy to have a long running series and periodically send updates to the list. I have a repository on github[1] which has an ipv6 branch collecting my changes if anyone wants to pull it down for their own testing. If we want to apply some of the simple stuff early that's fine by me.

Quoted 8 lines

Quoted 3 lines
I see no problem with handling this as a branch (for example in the u-boot-net or u-boot-testing repositories). This should probably be decided by Joe Hershberger, though.
I'm fine with hosting these changes as a branch in the u-boot-net repo.
-Joe

Sounds good to me. I wouldn't go creating it just yet as I'm re-rolling patches frequently. Once the initial round of development and review has settled down then having the code on a more public branch for people to test with would be good.

Chris Packham

author

2013-01-20 09:44 UTC #13 lore raw

v2 cover Initial IPv6 support

In reply to Wolfgang Denk

Quoted 11 lines · Wolfgang Denk

Dear Chris,
Quoted 5 lines · In message <[email protected]> you wrote:
Good question. Basically we have some out of tree code that implements a basic IPv6 stack. I'm drip feeding the code in pieces to avoid just dumping it on people and because the current code wouldn't meet u-boot's standards.
Can you please go into abit more detail which exact services this implements, and how?

TFTP over IPv6 as well as PING6. Our use case is just static address configuration but using link-local addresses should be doable. I was thinking it wouldn't be to hard to implement something to generate a global IPv6 address based on the eui-64 of the device.

Quoted 10 lines

Last time I checked (about 2 years ago) there was no officially agreed-on standard for example how network booting should be done in IPv6.
There used to be a document how TFTP could handle IPv6 addresses at
http://datatracker.ietf.org/idtracker/draft-evans-tftp-address-options/comment/50586/
but this apears to be gone now. The proposal was rejected by then, and the comments ("I do recommend the transition to a better transport protocol.") sounded as if the IETF would like to abandon TFTp under IPv6.

For TFTP it's just a matter of which addresses the server binds to, and whether the CLI accepts IPv6 addresses. I think we had a patch for tftp-hpa floating around which was only a few lines. I'm not sure it's even needed these days.

Quoted 7 lines

I found links for DHCPv6, for example
http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-opt-netboot-00
but no read standard for a bootstrap protocol. Some documents indicated it might be based on iSCSI - but that would be quite complex; see
http://tools.ietf.org/html/rfc4173
http://tools.ietf.org/agenda/72/slides/dhc-12.pdf

DHCPv6 has come along way. At least in terms of address assignment and interop with other IPv6 auto-configuration mechanisms. I'm not sure about the bootstrap side of things though.

Quoted 1 line

So what exactly are you targeting for?

A fairly narrow use-case initially - TFTP with a statically configured IPv6 address.

At $dayjob we have just added DHCPv6 to our Linux based switches (based on ISC dhcpd). I wasn't personally involved but it's something we might be able to help with if there was demand.

Quoted 18 lines

Quoted 1 line
Putting my IPv6 promoter hat on I hope that it won't stay dead for long :)
Thanks, appreciated!
Quoted 5 lines
Personally I'm happy to have a long running series and periodically send updates to the list. I have a repository on github[1] which has an ipv6 branch collecting my changes if anyone wants to pull it down for their own testing. If we want to apply some of the simple stuff early that's fine by me.
I see no problem with handling this as a branch (for example in the u-boot-net or u-boot-testing repositories). This should probably be decided by Joe Hershberger, though.
Best regards,
Wolfgang Denk

Albert ARIBAUD

2013-01-20 21:00 UTC #14 lore raw

v2 cover Initial IPv6 support

Hi Chris,

Quoted 6 lines · Chris Packham

TFTP over IPv6 as well as PING6. Our use case is just static address configuration but using link-local addresses should be doable. I was thinking it wouldn't be to hard to implement something to generate a global IPv6 address based on the eui-64 of the device.
[...]

Any chance IPv6 autoconfiguration RS/RA support is in the pipe? My provider here uses RAs.

Amicalement,

Signature · 1 line

Albert.

Chris Packham

author

2013-01-20 21:25 UTC #15 lore raw

v2 cover Initial IPv6 support

Quoted 10 lines · Albert ARIBAUD

Hi Chris,
Quoted 5 lines · Chris Packham
TFTP over IPv6 as well as PING6. Our use case is just static address configuration but using link-local addresses should be doable. I was thinking it wouldn't be to hard to implement something to generate a global IPv6 address based on the eui-64 of the device.

Quoted 9 lines

Quoted 1 line
[...]
Any chance IPv6 autoconfiguration RS/RA support is in the pipe? My provider here uses RAs.
Amicalement,
--
Albert.

Should be doable. RS/RA is a lot easier than DHCPv6 because we have to support neighbour solicitation anyway so router solicitation and the prefix delegation part shouldn't be much more work.

Chris Packham

author

2013-01-21 00:51 UTC #16 lore raw

v2 cover Initial IPv6 support

In reply to Chris Packham

Hi Wolfgang,

A a few more specific answers to your questions

Quoted 15 lines · Chris Packham

Quoted 8 lines · Wolfgang Denk
Dear Chris,
Last time I checked (about 2 years ago) there was no officially agreed-on standard for example how network booting should be done in IPv6.
There used to be a document how TFTP could handle IPv6 addresses at
http://datatracker.ietf.org/idtracker/draft-evans-tftp-address-options/comment/50586/
Quoted 4 lines
but this apears to be gone now. The proposal was rejected by then, and the comments ("I do recommend the transition to a better transport protocol.") sounded as if the IETF would like to abandon TFTp under IPv6.

Quoted 5 lines

For TFTP it's just a matter of which addresses the server binds to, and whether the CLI accepts IPv6 addresses. I think we had a patch for tftp-hpa floating around which was only a few lines. I'm not sure it's even needed these days.

As long as the bind is done with AF_UNSPEC then it will listen to either v4 or v6. You can explicitly force v4 or v6 by using AF_INET or AF_INET6. A modern version of tftp-hpa supports both AF_UNSPEC and AF_INET6. The IPv6 stack shouldn't care what application is being run over it. It's just udp as far as the stack is concerned.

Quoted 8 lines

Quoted 7 lines
I found links for DHCPv6, for example
http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-opt-netboot-00
but no read standard for a bootstrap protocol. Some documents indicated it might be based on iSCSI - but that would be quite complex; see
http://tools.ietf.org/html/rfc4173
http://tools.ietf.org/agenda/72/slides/dhc-12.pdf

Quoted 4 lines

DHCPv6 has come along way. At least in terms of address assignment and interop with other IPv6 auto-configuration mechanisms. I'm not sure about the bootstrap side of things though.

RFC5970[1] details network boot options for DHCPv6 (I think it's the ratified version of the draft you linked to). Basically this allows the server to specify a URL for the boot file which presumably could be something like tftp://[2001:db8::1]/uImage. Looks like the standard also covers passing kernel parameters and dealing with different architectures.

I'm not sure which, if any, dhcp6 server implementations support this RFC but it looks like the standards exist.

Thanks,
Chris
--
[1] - http://tools.ietf.org/html/rfc5970

Wolfgang Denk

2013-01-21 12:37 UTC #17 lore raw

v2 cover Initial IPv6 support

Dear Chris,

Quoted 7 lines · In message <CAFOYHZDN3sB56ZF3jx28y3opJhhU4uqyA-91vdhOU9DRwDN8Jw@mail.gmail.com>…

RFC5970[1] details network boot options for DHCPv6 (I think it's the ratified version of the draft you linked to). Basically this allows the server to specify a URL for the boot file which presumably could be something like tftp://[2001:db8::1]/uImage. Looks like the standard also covers passing kernel parameters and dealing with different architectures.

Quoted 7 lines

I'm not sure which, if any, dhcp6 server implementations support this RFC but it looks like the standards exist.
Thanks,
Chris
--
[1] - http://tools.ietf.org/html/rfc5970

I see. Thanks for the update!

Best regards,

Wolfgang Denk

Signature · 5 lines

DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Anyone can count the seeds in an apple.
No one can count the apples in a seed.

Wolfgang Denk

2013-01-18 10:25 UTC #18 lore raw

v2 cover Initial IPv6 support

In reply to Albert ARIBAUD

Dear Albert ARIBAUD,

Quoted 5 lines · In message <20130118092041.0c827374@lilith> you wrote:

Quoted 3 lines
This series so far covers the introduction of a IP6addr_t and printing/parsing of addresses.
As a general comment, I heartily welcome IPv6 support (even though I

Me too! :-)

Quoted 7 lines

but I wonder how this fits in with the general line of not adding dead code in U-Boot. Will we make an exception for IPv6 and accept this RFC once it is officially submitted? Or do we collect small, reviewable RFCs for various IPv6 aspects but apply them in one go? Or do we create a branch or tree where IPv6 will get integrated step by step until solid enough for mainline inclusion? Or was this decided already and I missed it?

My understanding was that this patch set was for reviewing purposes only (hence RFC). Your dead code hint is absolutely correct: for integration into mainline we need users of the code, i. e. for example DHCP and TFTP support...

Best regards,

Wolfgang Denk

Signature · 6 lines

DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
C++ was an interesting and valuable experiment, but we've learned its
lessons and it's time to move on.
                            - Peter Curran in <[email protected]>

Wolfgang Denk

2013-01-18 10:23 UTC #19 lore raw

v2 cover Initial IPv6 support

In reply to Chris Packham

Dear Chris,

Quoted 5 lines · In message <[email protected]> you…

This series so far covers the introduction of a IP6addr_t and printing/parsing of addresses. I have a patch for testing these basic things which I haven't included in this series yet. Is there a unittest facility for u-boot I should be using?

We use the DUTS ([1], [2]) for all kind of test cases (but note that I don't claim it's easy to get started with it).

[1] http://www.denx.de/wiki/DUTS/DUTSDocs
[2] http://git.denx.de/?p=duts.git

Quoted 5 lines

A few open questions
1) Presumably the majority of the actual V6 code would be included by a config option (CONFIG_IPV6). How far should I take that? Should the vsprintf code be conditional?

Yes, please.

Quoted 2 lines

2) Our current out of tree code parallels net.c and net.h. Should I continue this for the final version or integrate it into net.[ch].

This depends - if such integration can be done nicely, i. e. without too many new #ifdef's, then yes, please.

Quoted 3 lines

3) rxhand_f currently takes an IPaddr_t. I haven't looked at the usage of this yet but to support V6 this may need to be a new union or a void *.

What exactly is the question here?

Best regards,

Wolfgang Denk

Signature · 5 lines

DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Microsoft Multimedia:
You have nice graphics, sound and animations when the system crashes.

Chris Packham

author

2013-01-20 09:24 UTC #20 lore raw

v2 cover Initial IPv6 support

Quoted 26 lines · Wolfgang Denk

Dear Chris,
Quoted 5 lines · In message <[email protected]> you…
This series so far covers the introduction of a IP6addr_t and printing/parsing of addresses. I have a patch for testing these basic things which I haven't included in this series yet. Is there a unittest facility for u-boot I should be using?
We use the DUTS ([1], [2]) for all kind of test cases (but note that I don't claim it's easy to get started with it).
[1] http://www.denx.de/wiki/DUTS/DUTSDocs
[2] http://git.denx.de/?p=duts.git
Quoted 5 lines
A few open questions
1) Presumably the majority of the actual V6 code would be included by a config option (CONFIG_IPV6). How far should I take that? Should the vsprintf code be conditional?
Yes, please.
Quoted 2 lines
2) Our current out of tree code parallels net.c and net.h. Should I continue this for the final version or integrate it into net.[ch].

Quoted 8 lines

This depends - if such integration can be done nicely, i. e. without too many new #ifdef's, then yes, please.
Quoted 3 lines
3) rxhand_f currently takes an IPaddr_t. I haven't looked at the usage of this yet but to support V6 this may need to be a new union or a void *.
What exactly is the question here?

The POSIX solution for this is to use sockaddr which encompasses both v4 and v6 addresses (as well as other socket types). Do we want to add a wrapper type or just work with void *?

I also need to look at things that implement a rxhand_f just to see what they do with the IPaddr_t.

Quoted 5 lines

Best regards,
Wolfgang Denk

Wolfgang Denk

2013-01-21 12:39 UTC #21 lore raw

v2 cover Initial IPv6 support

Dear Chris,

Quoted 4 lines · In message <[email protected]> you wrote:

The POSIX solution for this is to use sockaddr which encompasses both v4 and v6 addresses (as well as other socket types). Do we want to add a wrapper type or just work with void *?

Without checking for implications for the implementation I would say that we should avoid void * and rather allow for better type checking.

Best regards,

Wolfgang Denk

Signature · 7 lines

DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
In the pitiful, multipage, connection-boxed form to which  the  flow-
chart  has  today  been  elaborated, it has proved to be useless as a
design tool -- programmers draw flowcharts after, not before, writing
the programs they describe.                        - Fred Brooks, Jr.