Subject: [Softwires] Comments on draft-townsley-ipv6-6rd-01.txt

From: Dave Thaler <[email-masked]>
Date: Sun, 8 Nov 2009 09:26:33 +0000

While this draft is a good start (and is arguably as good as the 6to4 spec was),
I think it still needs a bunch of work, as we've learned from the 6to4 experience.

First the draft needs to discuss the properties of IPv6 on the 6rd interface:

1)      What's the link model?  Presumably it's an NBMA interface like 6to4,
in which case multicast isn't supported.  But the document needs to
discuss this.

2)      One of the problems with 6to4 is that it violates the IPv6 RFCs by
not having a link-local address (see RFC 4291 section 2.1, section paragraph,
for example).    Will 6rd repeat that violation or not?
Can packets be sent with a link-local address?

3)      The use of Neighbor Discovery on the interface needs to be
discussed.  Are unicast RS/RA legal?  Presumably normal router discovery
and address resolution are not used since it's NBMA.  As RFC 4861 says:
> Unless specified otherwise (in a document that covers operating IP
> over a particular link type) this document applies to all link types.
> However, because ND uses link-layer multicast for some of its
> services, it is possible that on some link types (e.g., Non-Broadcast
> Multi-Access (NBMA) links), alternative protocols or mechanisms to
> implement those services will be specified (in the appropriate
> document covering the operation of IP over a particular link type).
> The services described in this document that are not directly
> dependent on multicast, such as Redirects, Next-hop determination,
> Neighbor Unreachability Detection, etc., are expected to be provided
> as specified in this document.
Since 6rd doesn't specify otherwise, I assume that redirects, next-hop
determination, NUD, etc are provided as specified in RFC 4861, correct?

Compare how ISATAP addresses these in RFC 5214 section 8, and 6RD
needs to have a similar level of coverage.

My second major concern with the current draft is that it is too limited
in scope compared to 6to4 where I believe it should be able to be used
in place of 6to4 (other than having private relays with a network-specific
prefix, instead of public relays with a well-known prefix).  Specifically
there are two limitations introduced without good reason, that need
to be removed:

1)      The draft says a CE must have 1 or more LAN interface.  6to4
can be used even when you don't have a LAN interface (up).
Remove this limitation, as it's not necessary and doesn't affect anything
else.

2)      The DHCP option format for configuring a CPE is only capable
of holding a single BR address.  To be able to replace 6to4, this must
be capable of passing a list.  Today many 6to4 gateways are capable
of using a list, and adding one default route for each relay address,
and this can facilitate load-spreading, failover, etc.  There's no
reason given to make 6rd less capable in this respect.  If a SP doesn't
want that, they don't have to provide more than 1 address, but
we should not prevent an SP from providing service equivalent to
what can be done with 6to4 today.

-Dave

---

From: Mark Townsley <[email-masked]>
Date: Mon, 09 Nov 2009 02:30:50 +0900

Dave - fyi draft-ietf-softwire-ipv6-6rd-01.txt is the latest spec, the 
draft-townsley version is retired. Thanks for the review, jetlagged comments 
inline...

Dave Thaler wrote:
> I think it still needs a bunch of work, as we’ve learned from the 6to4 
> experience.
>
> 1) What’s the link model? Presumably it’s an NBMA interface like 6to4,
>
> in which case multicast isn’t supported. But the document needs to
>
> discuss this.
>

Yes, it is, and perhaps we are relying too much on the 6to4 basis here.
I don't want to rewrite RFC3056 completely in this document, but we can
certainly try to be more clear here on the link-model.

> Can packets be sent with a link-local address?
Offhand, I see no need for a link-local here, but I think the right
thing to do would be to use the associated IPv4 address to create an
fe80:: link-local ala ISATAP.
> discussed. Are unicast RS/RA legal?
>
> Presumably normal router discovery
>
> and address resolution are not used since it’s NBMA.
>
Right, neighbor discovery inside the tunnel is not required.
> As RFC 4861 says:
> Since 6rd doesn’t specify otherwise, I assume that redirects, next-hop
>
So far this hasn't been important for the implementations we have, but
for completeness I agree we should specify this fully in the spec.
> can be used even when you don’t have a LAN interface (up).
>
> Remove this limitation, as it’s not necessary and doesn’t affect anything
>
> else.
>
Yes, of course, the CE could always be a host.
> and this can facilitate load-spreading, failover, etc. There’s no
>
> reason given to make 6rd less capable in this respect. If a SP doesn’t
>
> want that, they don’t have to provide more than 1 address, but
>
IPv4 anycast is an important part of the design here as it eliminates
the complexity associated with the CE keeping track of which BR to use.
It might seem trivial for a CE to have multiple BR addresses, but this
comes with responsibility and associated complexity of knowing which are
up, down, loaded or not, etc. 6rd is designed to operate in an SP
network utilizing as much IPv4 infrastructure as possible, that includes
load-balancing, failover, etc. provided by using a single IPv4 anycast
address.

- Mark
>
> -Dave
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires
>

---

From: Dave Thaler <[email-masked]>
Date: Sun, 8 Nov 2009 20:10:18 +0000

Mark Townley wrote:
[...]
> load-balancing, failover, etc. provided by using a single IPv4 anycast

That is not justification for preventing the use of multiple addresses.

I agree that use of an anycast is good, but we should not force this
on anyone.  There are also cases where use of multiple addresses
can provide much better load-splitting and failover than anycast can.

-Dave

---

From: "Templin, Fred L" <[email-masked]>
Date: Sun, 8 Nov 2009 12:31:38 -0800

In addition to Dave's comments, other concerns are:

- 6rd requires that CPE routers always assign a static
  IPv4 address in order to avoid IPv6 renumbering, i.e.,
  IPv6 prefix is inseparable from the IPv4 address. Hence,
  it is not compatible with dynamic IPv4 address autoconfig.

- Use of anycast does not allow the CPE router to select
  between multiple available exit routers. Instead, exit
  router selection is through IPv4 routing in the ISP
  network, which is non-deterministic from the CPE router's
  point of view.

- Non-use of IPv6 ND does not allow for dynamic configuration
  of lifetimes for default and more-specific routes. Also,
  no NUD mechanism.

- Tunnel path MTU is left to chance of the ISP operator's
  link deployment practices. Under-provisioned or
  mis-configured links will show up as sources of IP
  fragmentation.

- Reducing tunnel MTU to account for the encapsulation header
  (e.g., to 1480) ensures that hosts behind the CPE router
  will see unnecessarily excessive path MTU interactions.

- No means for migration to larger MTUs (e.g. 9KB) as links
  in the ISP network incrementally deploy larger MTUs.

Fred
[email-masked] 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark Townsley
> Sent: Sunday, November 08, 2009 9:31 AM
> To: Dave Thaler
> Cc: [email-masked]
> Subject: Re: [Softwires] Comments on draft-townsley-ipv6-6rd-01.txt
> 
> 
> > and address resolution are not used since it's NBMA.
> >

---

From: james woodyatt <[email-masked]>
Date: Sun, 8 Nov 2009 13:39:07 -0800

>  it is not compatible with dynamic IPv4 address autoconfig.

Not exactly.  It's true that 6RD couples IPv4 address assignment with  
IPv6 prefix assignment.  If the IPv4 address assignment is dynamic, it  
just means that the CPE router will have to renumber the local IPv6  
prefix whenever the IPv4 address changes.  This isn't supposed to be a  
crisis event with IPv6, like it seems to have become with IPv4, and  
experience with 6to4 router implementations as residential gateways  
shows that dynamic IPv6 prefix renumbering isn't enough of a problem  
to make 6RD inappropriate for IPv6 transition engineering.

>  network, which is non-deterministic from the CPE router's

Having a fair amount of experience with implementing residential CPE  
dual-stack IPv4/IPv6 gateway routers, I hope I have some authority  
with which to declare this as a FEATURE and not a problem.  Not having  
to burden the residential user with having to choose an IPv6 relay  
endpoint on their own, when this is really something the service  
provider should be handling transparently to the subscriber, seems  
like a desirable quality in a protocol for our purposes here.

>  of lifetimes for default and more-specific routes. Also,

What?  Seriously, I don't understand the concern behind this comment.   
Could you elaborate?

>  mis-configured links will show up as sources of IP

I suppose it would help if the specification made explicit the need  
for IPv4 path MTU discovery to work, i.e. there must be a clear path  
for ICMP4 errors to pass on the same path as the proto 41 packets, and  
both tunnel endpoints need to cope with the path MTU discovery problem  
appropriately.

>  will see unnecessarily excessive path MTU interactions.

Depends on your expectations for the necessity of path MTU discovery.   
I don't see how there is a problem: the CPE router and the 6RD relay  
negotiate the path MTU shortly after the CPE router obtains its 6RD  
configuration, and one would expect the path MTU to be relatively  
stable over time in a real-world deployment.

>  in the ISP network incrementally deploy larger MTUs.

The migration path is to go native IPv6, if you ask me.  Again, I view  
this as a feature: it provides for a natural sunset provision.

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

---

From: "Templin, Fred L" <[email-masked]>
Date: Sun, 8 Nov 2009 14:44:03 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of james woodyatt
> Sent: Sunday, November 08, 2009 1:39 PM
> To: [email-masked]
> Not exactly.

I'm not sure how you mean "not exactly"?

> It's true that 6RD couples IPv4 address assignment with
> IPv6 prefix assignment.

That is exactly what I am saying.

> If the IPv4 address assignment is dynamic, it
> prefix whenever the IPv4 address changes.

You mean renumber the global IPv6 prefix, right? This
renumbering has to percolate all the way down through
the customer premises.

> This isn't supposed to be a

We have seen evidence that "renumbering still needs work",
even in IPv6.

> like a desirable quality in a protocol for our purposes here.

You may have missed an aspect of my point, or I may not have
expressed it fully. When the CPE router discovers addresses
of ISP border routers and performs neighbor discovery
exchanges with them, the ISP is still the one that informs
the CPE routers of best choices. So, this is not a "burden"
on the CPE router, and the ISP still has the means to
engineer the traffic. It simply gives the CPE router the
means to make the best choices based on what the ISP
tells it.

> What?  Seriously, I don't understand the concern behind this comment.

Like when an RA advertises a PIO or an RIO they have
lifetimes that the CPE router learns. These lifetimes
influence router selection and router reachability in
a way that is not available without them. 

> both tunnel endpoints need to cope with the path MTU discovery problem

The only way to ensure this is to ensure that there will
be no ICMP filtering and to ensure that there can be no
source address spoofing inside of the ISP network. Then,
if you want to leverage IPv4 path MTU discovery instead
of defer to IPv4 fragmentation the CPE routers will need
to maintain a neighbor cache with per-neighbor MTU values,
which adds state to an otherwise stateless model.
 
> stable over time in a real-world deployment.

When applications start up on hosts that connect to a
1500 link, they will often want to send 1500 packets.
Even if the CPE router were to cache smaller per
neighbor MTUs (state), the hosts will often be
disappointed to see their 1500 packets dropped and
need to ratchet down their path MTU estimates. But
for hosts, path MTU is per-destination (not per-
neighbor) so they will try again with 1500s for each
distinct destination even if they keep getting denied
by the CPE. This is the way path MTU discovery works,
but the optimum condition is to not invoke path MTU
discovery at all if possible.

> this as a feature: it provides for a natural sunset provision.

This is obviously a matter for debate. Native IPv6 at
the edges is a yes for sure; IPv6 in the middle is a
matter for open debate since a well-deployed tunneling
scenario may make it unnecessary.

Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Sun, 8 Nov 2009 16:36:35 -0800

It has not been talked about much, but ISATAP is capable
of supporting router-to-router tunneling. When an ISATAP
router receives a packet that appears to have come through
another router, it can check its local forwarding table
using an RPF check to see if there is a corresponding
IPv6 route. If there is a route, it accepts the packet.

Routes can get into the ISATAP router's IPv6 forwarding
table in a couple of ways. First, the router can run
a dynamic IPv6 routing protocol with other routers as
neighbors on the ISATAP interface. Second, the router
can receive and exchange Route Information Options in
IPv6 ND RA messages with other ISATAP routers. Other
methods are also possible.

Given router-to-router tunneling, ISATAP fits the
same use case scenario as 6rd. It moreover fits other
use case domains that might not be such a good fit
for 6rd, including enterprise networks, MANETs, etc.
I have router-to-router tunneling support coded and
tested in the linux kernel.

Fred

---

From: Ole Troan <[email-masked]>
Date: Mon, 9 Nov 2009 10:07:21 +0900

Fred,

> tested in the linux kernel.

I don't quite understand how this would work. are you suggesting doing  
DHCP PD and then advertise the delegated prefix in a dynamic routing  
protocol? one big difference from 6rd would in that case be the amount  
of state required.

if you think this is a worthwhile idea then a draft would be good. I  
at least can't read this deployment model out of the ISATAP RFC.

cheers,
Ole

---

From: "Templin, Fred L" <[email-masked]>
Date: Sun, 8 Nov 2009 17:13:43 -0800

Ole,

> From: Ole Troan [mailto:[email-masked]] On Behalf Of Ole Troan
> Sent: Sunday, November 08, 2009 5:07 PM
> To: Templin, Fred L
> Cc: [email-masked]
> Subject: Re: [Softwires] Router-to-router tunneling in ISATAP
> 
> Fred,
> 

DHCP PD is certainly one way an ISATAP router could
receive an IPv6 prefix that it can sub-delegate to
its downstream-attached links. Dynamic routing protocol
is one way that the prefix can get disseminated to other
ISATAP routers, but it is not the only way. The VET spec
talks more about this.
 
> at least can't read this deployment model out of the ISATAP RFC.

The ISATAP spec only talks about the operation of
neighbor discovery over an NBMA link manifested by
tunneling, i.e., it is an IPv6-over-foo document. It
is therefore not within scope for ISATAP to talk about
higher layer considerations. Again, the VET spec talks
about the higher layer considerations, but dynamic
routing protocols can certainly treat the ISATAP
link the same as for any IPv6 link.

Fred

---

From: Ole Troan <[email-masked]>
Date: Mon, 9 Nov 2009 10:30:42 +0900

Fred,

> a way that is not available without them.

we're talking about a router to router link here. you appear to be  
suggesting to use ND as a routing protocol. I don't think that is  
specified anywhere.

for more specific routes you need to run a routing protocol between  
the BRs and the CEs. which routing protocol do you use? do you need to  
provide a way of automatically provisioning the routing protocol?

for the multiple BR problem, this can also be solves with a dynamic  
routing protocol or one could use BFD.

again, we wanted 6rd to be stateless. and possibly we were too lazy to  
try to solve all these issues... :-)

cheers,
Ole

---

From: "Templin, Fred L" <[email-masked]>
Date: Sun, 8 Nov 2009 17:32:31 -0800

Ole,

> Sent: Sunday, November 08, 2009 5:31 PM
> To: Templin, Fred L
> Cc: james woodyatt; [email-masked]

Yes it is; it is specified in VET.

Fred

---

From: Mark Smith <[email-masked]>
Date: Mon, 9 Nov 2009 20:18:12 +1030

Hi,

A few questions -

On Sun, 8 Nov 2009 14:44:03 -0800

> > On Nov 8, 2009, at 12:31 , Templin, Fred L wrote:

<snip> 

> means to make the best choices based on what the ISP

If it's the IPv4 layer/BR address being talked about, I'm curious as to
what mechanism is to be used to express the IPv4 Border Router address
preferences, how their availability is to be tracked, and how the
preferences are to be updated, if necessary? The only IPv4 mechanism
I'm aware of that can achieve those sorts of functions are fully
fledged routing protocols (as "fully fledged" as RIP might be).

If the BR IPv4 address or addresses were somehow encoded in IPv6 link
local addresses, then IPv6 RA router preferences might be able to be
shoehorned into indicating BR IPv4 preference. 

<snip>

> scenario may make it unnecessary.

If 9K MTUs are migrated to, hiding the tunnel overhead, then the CPE
could stop announcing an RA MTU that is smaller than the CPE's
downstream LAN MTU.

Regards,
Mark.

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 9 Nov 2009 02:52:51 -0800

Mark - brief answer below:

> From: Mark Smith [mailto:[email-masked]]
> Sent: Monday, November 09, 2009 1:48 AM
> To: Templin, Fred L

ISATAP provides just such a mechanism, so I think you
answered your own question.

Fred

---

From: Dave Thaler <[email-masked]>
Date: Mon, 9 Nov 2009 11:25:18 +0000

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Ole Troan
> Sent: Monday, November 09, 2009 10:31 AM
> To: Templin, Fred L
> Cc: [email-masked]
> >>> - Use of anycast does not allow the CPE router to select between
> >>> multiple available exit routers. Instead, exit router selection is
> >>> through IPv4 routing in the ISP network, which is non-deterministic
> >>> from the CPE router's point of view.
> >>
> expressed
> > it fully. When the CPE router discovers addresses of ISP border
> > routers and performs neighbor discovery exchanges with them, the ISP
> > is still the one that informs the CPE routers of best choices. So,
> > this is not a "burden"
> > on the CPE router, and the ISP still has the means to engineer the
> > traffic. It simply gives the CPE router the means to make the best
> > choices based on what the ISP tells it.
> >
> >>> - Non-use of IPv6 ND does not allow for dynamic configuration of
> >>> lifetimes for default and more-specific routes. Also, no NUD
> >>> mechanism.
> >>
> > Like when an RA advertises a PIO or an RIO they have lifetimes that
> > the CPE router learns. These lifetimes influence router selection and
> > router reachability in a way that is not available without them.
> 
> we're talking about a router to router link here. 

No we're not.  We're talking about a link that can have _both routers
and hosts_ on it.  From Mark's email earlier in this thread responding 
to me:

  > > Remove this limitation, as it's not necessary and doesn't affect 
  > > anything else.
  >

> you appear to be

ND is not a routing protocol.  RD is not a routing protocol per se
either, but it can distribute routing information to hosts.
See RFC 4191 (which is optional) for more information.
NUD is not a routing protocol, but it does allow nodes to obtain
liveness information about another node on the link.

And we have existing RFCs that say how hosts select among multiple
routers on link.  RFC 4861 talks about using liveness information
(see 5.2).  RFC 4311 (which is optional) talks about how a host
can use multiple default gateways simultaneously.  However nothing
_requires_ the host to do any of the above, and a host could simply
take the first address and ignore all the rest.  So what James 
wants (simplicity of implementation) is not precluded in any way
by passing a list.  However, not being capable of having a list
precludes how 6to4 is used today in some environments, 
even in the same scenario 6rd is designed for.  Passing a list
doesn't require defining anything new, nor does it require
any complex implementation on hosts or routers.

-Dave

> 
> for more specific routes you need to run a routing protocol between the
> BRs and the CEs. which routing protocol do you use? do you need to

---

From: Ole Troan <[email-masked]>
Date: Tue, 10 Nov 2009 11:37:11 +0900

Dave,

[...]

> and hosts_ on it.  From Mark's email earlier in this thread responding

I don't see any reason why one couldn't implement 6rd in a host. the  
base specification does specify this only for routers though. just  
like rfc3056 does.

> any complex implementation on hosts or routers.

we want as far as possible for implementors to be able to reuse  
existing 6to4 code. 6to4 doesn't specify how multiple relays are used  
either. rfc3068 specifies how a single anycast address is used to  
reach a relay.

6rd can be provisioned in multiple ways and there is nothing stopping  
one from deploying with multiple relays. we _could_ add a list of  
relays in the DHCP option in 6rd. my only concern is that would we  
then have to add text to describe how one should switch between them?  
e.g NUD or BFD to detect liveness... this would be new code in  
comparison to a vanilla 6to4 implementation.

cheers,
Ole

---

From: Dave Thaler <[email-masked]>
Date: Tue, 10 Nov 2009 10:30:25 +0000

> base specification does specify this only for routers though. just

In hindsight, I think RFC 3056 should have mentioned the host case too.
I disagree that 3056 omitting it means we should omit it now too.

Omitting it just leads people to believe
"we're talking about a router to router link here"
as you've illustrated :-)

[...]
[...]
	
No.  However, someone pointed out to me that unlike a DHCPv6 option, 
a DHCPv4 option can occur multiple times.  Assuming that's correct, 
you can already get a list, in which case this particular concern of
mine goes away.

However, while we're on the topic of "reuse existing 6to4 code", it probably
would have been better to call 6rd a "6to4 extension for private relays",
rather than a new protocol name since we have enough names to teach
people already and people just think "we have too many".  If you actually 
configured a 6RD node with a 6rd SP prefix of 2002::/16, you ought to 
get behavior identical to 6to4 behavior.  So our task would just be 
updating 6to4 to allow for a configured prefix, and perhaps anything 
else required.

-Dave

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 11 Nov 2009 01:40:27 +1300

On 2009-11-10 23:30, Dave Thaler wrote:
...
> I disagree that 3056 omitting it means we should omit it now too.

In defence of 3056, here's what it says:

   Although the mechanism is specified for an IPv6 site, it can equally
   be applied to an individual IPv6 host or very small site, as long as
   it has at least one globally unique IPv4 address.  However, the
   latter case raises serious scaling issues which are the subject of
   further study [SCALE].

That reference is to

   [SCALE]    Hain, T., "6to4-relay discovery and scaling", Work in
              Progress.

(http://tools.ietf.org/html/draft-hain-6to4-scaling-01),
which I fear went nowhere, or was overtaken by RFC3068.

   Brian

---

From: Dave Thaler <[email-masked]>
Date: Tue, 10 Nov 2009 12:42:21 +0000

The text
"  Although the mechanism is specified for an IPv6 site, it can equally
   be applied to an individual IPv6 host or very small site, as long as
   it has at least one globally unique IPv4 address."
is good.  I would like to see such text added to the 6rd doc.

Thanks for the defence Brian.

-Dave

> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Tuesday, November 10, 2009 9:40 PM
> To: Dave Thaler
> Cc: Ole Troan; [email-masked]
> Subject: Host 6to4 [Comments on draft-townsley-ipv6-6rd-01.txt]
>

---

From: Pekka Savola <[email-masked]>
Date: Tue, 10 Nov 2009 15:12:07 +0200 (EET)

> I disagree that 3056 omitting it means we should omit it now too.

RFC 3056 could be called a success because it has been (almost?) 
solely been used in ways not originally envisioned (or at least 
written to the spec).

>From the current usage perspective, RFC 3056 as a specification is not 
very useful, and I would strongly urge us not to copy it.  If 3056bis 
is ever written, I'd personally want to see it written very, very 
differently :-)

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 10 Nov 2009 05:35:41 -0800

Dave and Ole,

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Dave Thaler
> Sent: Tuesday, November 10, 2009 2:30 AM
> To: Ole Troan
> Cc: [email-masked]

Host-based 6rd is certainly a possibility (as also
confirmed by Brian's account of the 6to4 text). Also
possible is to run 6rd to routers in the ISP network
that are also configured as ISATAP routers. Then,
hosts can use PRL router discovery and get IPv6
service via ISATAP using their pre-existing code.

Fred

---

From: Mark Smith <[email-masked]>
Date: Wed, 11 Nov 2009 07:08:09 +1030

On Tue, 10 Nov 2009 05:35:41 -0800

> service via ISATAP using their pre-existing code.

It seems to me that ISATAP might have more of the features that are the
goal of 6rd when compared with 6to4, with the exception of that ISATAP
is host-to-router rather than router-to-router, and there isn't
currently a way to derive a delegatable prefix from an ISATAP node
address.

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 10 Nov 2009 15:08:52 -0800

> Sent: Tuesday, November 10, 2009 12:38 PM
> To: Templin, Fred L
> Cc: Dave Thaler; Ole Troan; [email-masked]

6to4, ISATAP, Teredo and now 6rd are really just all
members of the same family. 6to4 is the kindly single
parent that works hard to support her children. ISATAP
is the nerd that stays home reading physics textbooks
while the other kids are out back playing stickball.
Teredo is the prankster that throws snowballs at cars
and soaps the neighbors windows. Now, 6rd is the
shining new baby, full of potential. Welcome to the
family, kid.

Fred